https://bugs.winehq.org/show_bug.cgi?id=54243 --- Comment #5 from Matthew Ogilvie <mmogilvi2+wine(a)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?) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.