http://bugs.winehq.org/show_bug.cgi?id=2356
------- Additional Comments From klaus.piemont@gmx.de 2004-12-07 17:02 -------
Your program doesn't know anything about a Linux file system. Perhaps it did an API call to see what the filesystem is and follows the result (VFAT, NTFS, Network, CDROM etc. ).
That is the funny thing. I have no idea why this call was made in the first place. Let me get this a little bit clearer. What you do in DVDlab is that you select the mpeg files from some explorer like window into a filelist. This part works. In the filelist you see the filename, the path (including the driveletter) and some attributes like frame size. This means that at that point DVDlab must have had opened the file already once to get that internal information. In a second operation you select a file from the filelist and insert it into the project. And here it fails. The area where normaly thumbnails of the movie are shown remains simply black. I can't think of any possible reason why the drive itself should be accessed at this point, since every information needed is already in the filelist shown. A simple open file for read should do the job. Maybe it is not even intended by the programmer, but he uses a library which does this internaly. Don't know.
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.
Not possible, it is a windows program that has no knowledge about "logical" wine HD's. The program "knows" that it is a Windows volume, and wine has to emulate
that.
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.
As far as I understand what you want is a way to make the emulated "L:" behave the same way whether dosdevices/l: points to a mount point or not.
Here we are. That was my intention. I had this kind of control up to wine 20040404 where I could specify "HD" in the config file and everything was clear. 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.
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
-
Wine Bugs