http://bugs.winehq.org/show_bug.cgi?id=10957
Summary: CreateFile doesn't work for devices Product: Wine Version: CVS/GIT Platform: Other OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-kernel AssignedTo: wine-bugs@winehq.org ReportedBy: rmh@aybabtu.com
According to MSDN, CreateFile can be used to obtain a handle on a device on which DeviceIoControl can be performed. Also, code in kernel32/volume.c:GetVolumeInformationW seems to rely on this.
However, wine always fails with error code 2 (file not found). The following test case illustrates this:
http://msdn2.microsoft.com/en-us/library/aa363147(VS.85).aspx
I've tested their code both on native winxp and win98. It works fine on winxp but fails on win98 (with error 2 too, like wine).
http://bugs.winehq.org/show_bug.cgi?id=10957
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #1 from Vitaliy Margolen vitaliy@kievinfo.com 2007-12-29 21:01:34 --- Everything works perfectly. Wine just does not have such a dive as used in example.
http://bugs.winehq.org/show_bug.cgi?id=10957
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #2 from Vitaliy Margolen vitaliy@kievinfo.com 2007-12-29 21:01:45 --- Closing invalid.
http://bugs.winehq.org/show_bug.cgi?id=10957
Robert Millan rmh@aybabtu.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|INVALID |
--- Comment #3 from Robert Millan rmh@aybabtu.com 2007-12-30 06:16:09 --- Try changing it.
On XP, the test works with "\\.\PhysicalDrive0" but also with "\\.\C:".
On wine, it is kernel32/volume.c:GetVolumeInformationW itself that assumes this will work.
http://bugs.winehq.org/show_bug.cgi?id=10957
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WORKSFORME
--- Comment #4 from Vitaliy Margolen vitaliy@kievinfo.com 2007-12-30 09:14:34 --- Works perfectly with "\\.\C:". Show the exact code, and exact errors you are getting. And no, the kernel32 is not the place that has something to do with this. Read the code!
http://bugs.winehq.org/show_bug.cgi?id=10957
Robert Millan rmh@aybabtu.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|WORKSFORME |
--- Comment #5 from Robert Millan rmh@aybabtu.com 2007-12-30 09:40:00 --- As I said, it returns error code 2 (file not found). The exact format in which the test represents that is:
"GetDriveGeometry failed. Error 2."
As for showing the "exact" code, it's in http://msdn2.microsoft.com/en-us/library/aa363147(VS.85).aspx and I can't really copy it to this Bugzilla without infringing Microsoft's copyright.
With regards to reading kernel32 code, as you could guess I've already done so.
I was hoping you'd provide some useful input for fixing this bug. Seeing this is not going to happen, I'll get back to the code and try to fix it by myself.
Sorry for bothering.
http://bugs.winehq.org/show_bug.cgi?id=10957
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |DUPLICATE
--- Comment #6 from Dmitry Timoshkov dmitry@codeweavers.com 2007-12-30 09:48:27 --- (In reply to comment #5)
As I said, it returns error code 2 (file not found). The exact format in which the test represents that is: "GetDriveGeometry failed. Error 2." As for showing the "exact" code, it's in http://msdn2.microsoft.com/en-us/library/aa363147(VS.85).aspx
The this bug is a duplicate.
*** This bug has been marked as a duplicate of bug 10018 ***
http://bugs.winehq.org/show_bug.cgi?id=10957
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Dmitry Timoshkov dmitry@codeweavers.com 2007-12-30 09:48:55 --- s/the/then/
Closing.
http://bugs.winehq.org/show_bug.cgi?id=10957
--- Comment #8 from Vitaliy Margolen vitaliy@kievinfo.com 2007-12-30 09:51:06 --- Created an attachment (id=9908) --> (http://bugs.winehq.org/attachment.cgi?id=9908) Sameple test program to return CD-ROM SCSI information
If you think that you can use any msdn examples as-is and expect them to work - you are nuts! Here is the example of how it _REALLY WORKS_ and been working for past 5 years at least (if not more).
The part that you don't get is that you have to have access to the device (which you apparently don't have).
http://bugs.winehq.org/show_bug.cgi?id=10957
--- Comment #9 from Robert Millan rmh@aybabtu.com 2007-12-30 10:31:17 --- Just in case someone runs through this, it turns out when loopback-mounting images whose name contains spaces, util-linux mount escapes them in /etc/mtab in a way wine doesn't parse well. I'm still unsure if it's a mount bug or a wine bug, will investigate.
As for "C:" not working where there isn't a real device for it, maybe it'd be good if wine emulated that, but not a big deal for applications out there I suppose.
And then as for "PhysicalDrive0" magic, I haven't seen any situation where this would be needed either.
Dmitry, after this explanation, are you still sure this is the same as bug 10018 ? I haven't looked at that bug in detail, but it seems to be something unrelated to the /etc/mtab issue.
http://bugs.winehq.org/show_bug.cgi?id=10957
--- Comment #10 from Dmitry Timoshkov dmitry@codeweavers.com 2007-12-30 11:04:04 --- (In reply to comment #9)
Dmitry, after this explanation, are you still sure this is the same as bug 10018 ? I haven't looked at that bug in detail, but it seems to be something unrelated to the /etc/mtab issue.
My reaction was to the sample code you have pointed out, since there were no other details about the problem.
http://bugs.winehq.org/show_bug.cgi?id=10957
--- Comment #11 from Robert Millan rmh@aybabtu.com 2007-12-30 11:54:23 --- Created an attachment (id=9915) --> (http://bugs.winehq.org/attachment.cgi?id=9915) fix handling of loopback drives
Ok, just found the problem. It only happens in a specific situation. To reproduce (in this example with drive D:, mapped to /media/cdrom0):
sudo mount image.iso /media/cdrom0 -o loop mv image.iso image2.iso
at this point, wine will be incapable of volume access on D:, because the code in ntdll/directory.c:parse_mount_entries() contains a sanity check to require that image.iso is a regular file. However, image.iso may not even exist!
Attached patch fixes this by allowing either the file to exist and be a regular file, or not exist at all (as long as its loopback device exists, of course).
(Note: This fix has nothing to do with supporting this on C: or PhysicalDrive:. Besides, I don't think there's much point in trying to support those since chances are they're rarely used)
http://bugs.winehq.org/show_bug.cgi?id=10957
Robert Millan rmh@aybabtu.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|DUPLICATE |
--- Comment #12 from Robert Millan rmh@aybabtu.com 2007-12-30 11:55:19 --- reopen
http://bugs.winehq.org/show_bug.cgi?id=10957
--- Comment #13 from Roderick Colenbrander thunderbird2k@gmx.net 2007-12-30 12:02:01 --- Assuming this patch (I don't know anything about this area) works, how are you attaching a device (/dev/..) to the mounted cdrom image? As that is needed by most apps for a cdrom drive in order to read e.g. the title.
Further it might also be useful to test if 'cdemu' also works fine. Cdemu can do the same as the standard 'mount -t iso9660' but it also supports other cdrom formats (e.g. cue/bin stuff) and this app at least provides device files. (Cdemu is the linux-equivalent of daemon tools)
http://bugs.winehq.org/show_bug.cgi?id=10957
--- Comment #14 from Robert Millan rmh@aybabtu.com 2007-12-30 12:12:35 --- (In reply to comment #13)
Assuming this patch (I don't know anything about this area) works, how are you attaching a device (/dev/..) to the mounted cdrom image? As that is needed by most apps for a cdrom drive in order to read e.g. the title.
It's implicit in the "mount file /mnt -o loop" command. Recent mount versions invoke losetup for you.
Further it might also be useful to test if 'cdemu' also works fine. Cdemu can do the same as the standard 'mount -t iso9660' but it also supports other cdrom formats (e.g. cue/bin stuff) and this app at least provides device files. (Cdemu is the linux-equivalent of daemon tools)
I don't think it makes any difference. IIRC cdemu is a more powerful equivalent to losetup. You can mount its devices the same way with -o loop=/dev/whatever.
http://bugs.winehq.org/show_bug.cgi?id=10957
Robert Millan rmh@aybabtu.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=10957
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|other |Linux
--- Comment #15 from Vitaliy Margolen vitaliy@kievinfo.com 2007-12-31 00:11:37 --- You can't delete a file and hope something else pick it up. For everything it's gone. So I doubt your "solution" is a a good one. Just don't remove the image file. Of course you are welcome to send your patch to wine-patches and see what happens.
http://bugs.winehq.org/show_bug.cgi?id=10957
--- Comment #16 from Robert Millan rmh@aybabtu.com 2007-12-31 03:32:08 --- (In reply to comment #15)
You can't delete a file and hope something else pick it up. For everything it's gone. So I doubt your "solution" is a a good one. Just don't remove the image file. Of course you are welcome to send your patch to wine-patches and see what happens.
The underlying loopback interface is based on i-nodes, not files. A file is just a way to refer it to the i-node that corresponds to your data. For this reason after the file has been renamed (and not necessarily "deleted" as such), you may still access its content via /dev/loop0.
You may argue that this is in fact a bug and /etc/mtab should be updated automatically, but solving that is impossible because the design of this scheme relies on subsequent invocations of mount for any update of that file. Of course this wouldn't happen if /etc/mtab was a symlink to /proc/mounts, but then we wouldn't have to worry about loopbacks at all.
You may also argue that users who rename images after setting loopbacks on them actually deserve this result because they made a mistake. I disagree. I think programs should be smarter than users and try to respond reasonably to their mistakes whenever this makes sense and doesn't compromise other areas. Programs are there to serve the user, not the other way around.
http://bugs.winehq.org/show_bug.cgi?id=10957
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase
http://bugs.winehq.org/show_bug.cgi?id=10957
--- Comment #17 from Austin English austinenglish@gmail.com 2008-10-23 15:17:09 --- Is this still an issue in current (1.1.6 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=10957
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified
--- Comment #18 from Austin English austinenglish@gmail.com 2009-01-18 03:47:31 --- Removing deprecated CVS/GIT version tag. Please retest in current git. If the bug is still present in today's wine, but was not present in some earlier version of wine, please update version field to earliest known version of wine that had the bug. Thanks!
http://bugs.winehq.org/show_bug.cgi?id=10957
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |nerv@dawncrow.de Resolution| |FIXED
--- Comment #19 from André H. nerv@dawncrow.de 2009-07-21 13:02:53 --- i cant confirm this in wine 1.1.26
http://bugs.winehq.org/show_bug.cgi?id=10957
Robert Millan rmh@aybabtu.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|FIXED |
--- Comment #20 from Robert Millan rmh@aybabtu.com 2009-07-21 15:41:02 --- This bug's not fixed. André just confirmed it.
http://bugs.winehq.org/show_bug.cgi?id=10957
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #21 from André H. nerv@dawncrow.de 2009-07-22 10:45:01 --- (In reply to comment #20)
This bug's not fixed. André just confirmed it.
No, i said i can not confirm it. that means the bug should be fixed.
http://bugs.winehq.org/show_bug.cgi?id=10957
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #22 from Alexandre Julliard julliard@winehq.org 2009-08-07 12:07:19 --- Closing bugs fixed in 1.1.27.
-
wine-bugs＠winehq.org