http://bugs.winehq.org/show_bug.cgi?id=2356
------- Additional Comments From rklazes@xs4all.nl 2004-13-07 06:08 -------
I was thinking it was the RW permissions of /dev/hdb5 .
Maybe or maybe not. If I where Linux I would never let any program accessing a mounted partition directly. But I'm rather a newbie in the Linux world and does not know much about the internals.
Linux allows this (with the right perms set) and Windows allows this. You should at least try the result with Read permissions.
That is exactly what I was trying to state. And for that reason the resolving of the drive letter L: directly to the device /dev/hdb5 makes no sense. Wine should return a simulated windows volume which is actually mapped through the wine layer to the directory structure.
In Windows "return a simulated windows volume" *means* a device and *not* a directory or file. In your case is asks for a volume and not a directory or file. And Wine is never bothered whether is makes sense or not.
Therefor I came up with the idea to depend the behavior on the filesystem in fstab. A harddisk filesystem means to ignore that dosdevices/l: points to a mount point and the path is handled the same way as any other path. Maybe one could add a override possibility in the config file to reactivate the current behaviour for a drive lette, even if I could not think about an app which would require this.
Ignoring the possibility that some unrelated bug is confusing us, there is already one application that is using this feature: yours. By some luck your application works when wine cannot find the device, but the next time you may not be lucky again. In this light I believe it is unlikely that such a change would be allowed in the official Wine tree. Rather look for a workaround with the dosdevices/l:: link, perhaps pointing it to /dev/null or /dev/zero works.
Did you happen to notice what the CreateFile() returns and what the LastError() was in those cases?
I'm sorry, but I have not. I was happy enough to get to the source of my problem by scanning through the code. I never had really worked with the windows api and this information was rather meaningless for me. Since programming in Java for several years now I found even reading C a bit of an adventure :D
Create a +relay,+file logfile by running wine like:
WINEDEBUG=+relay,+file wine ... &>wine.log
(fill in the dots with your program and arguments)
Open in an editor and search for the offending CreateFile() kernel call. Next look for the return and note the "ret=value". A value of ffffffff or 0 is an error, a small integer is success. Look for an GetLastError() call following this. The return value indicates the reason for the failure, error codes are in include/winerror.h
Create an attachment with part of the logs, so we can have a look.
-
Wine Bugs