https://bugs.winehq.org/show_bug.cgi?id=54243
--- Comment #5 from Matthew Ogilvie mmogilvi2+wine@gmail.com --- SIMPLER WORKAROUND: I just discovered that removing the "d::" symlink completely works (or don't create it in the first place), as long as the read-only .iso FS is loop mounted where "d:" indicates. (Contrary to the appdb "Howto" instructions.)
----
(In reply to Hans Leidekker from comment #4)
Wine can't do anything with the .iso file, it should point to the device file instead.
You make a good point that wine obviously can't make any CD-ROM drive-specific ioctl() calls on a .iso file. (Especially relevant for mixed data/music CD's from a slightly older era, including the original DOS version of Warcraft 2 (non-BNE). "cdemu" is probably very useful in such cases.)
But it still seems like wine shouldn't get internally confused and return information about writeable "Z:" when the application asks for GetVolumeInformation() about read-only "D:". It used to to work before version 7, and linking "d::" to the .iso is still documented in the appdb...
Maybe wine should log a helpful warning if it detects the double-colon symlink pointing to a file instead of a device? As is, I couldn't find any hints about exactly how things were failing and how to work around them until I dug into git history and the source code... (Tangent: Are there any cases where a file makes sense? Maybe if it is a hard disk image instead of a CD image, to support (hypothetical) applications that want to read/write to a raw disk directly? Does wine support any such applications at all?)