[Bug 2356] HD reported as device when mountpoint matches logical link in dosdevices

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=2356





------- Additional Comments From rklazes(a)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.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.