July 2004 - Wine-Bugs - list.winehq.org

[Bug 2356] HD reported as device when mountpoint matches logical link in dosdevices
by Wine Bugs July 13, 2004

July 13, 2004

http://bugs.winehq.org/show_bug.cgi?id=2356 ------- Additional Comments From rklazes(a)xs4all.nl 2004-13-07 06:15 ------- > I can verify that this is also the case for wine-20040615. > If I have a symlink in ~/.wine/dosdevices that points to a directory that is > listed in /etc/fstab, then some applications are unable to open that drive in > their file open/save dialogues (notably, word2k and excel2k). Unfortunatley I don't have word or excel installed. Just using notepad, I do not see any problem. Can you try with notepad or find some other similar small application? -- 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.

1 0

[Bug 2356] HD reported as device when mountpoint matches logical link in dosdevices
by Wine Bugs July 13, 2004

July 13, 2004

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.

1 0

[Bug 2356] HD reported as device when mountpoint matches logical link in dosdevices
by Wine Bugs July 13, 2004

July 13, 2004

http://bugs.winehq.org/show_bug.cgi?id=2356 winehq(a)nanonanonano.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq(a)nanonanonano.net ------- Additional Comments From winehq(a)nanonanonano.net 2004-13-07 04:14 ------- I can verify that this is also the case for wine-20040615. If I have a symlink in ~/.wine/dosdevices that points to a directory that is listed in /etc/fstab, then some applications are unable to open that drive in their file open/save dialogues (notably, word2k and excel2k). i.e.: e: -> /tmp /dev/hda6 -> /tmp Causes word2k and excel2k to be unable to access the e: drive from the file-open and file-save dialogues. An "access denied" error is shown if you go via the icon, but not if you go via the quick-pick dropdown box at the top (silently fails). If, however, the symlink is to a directory that is not listed in fstab, then it works fine. i.e. e: -> /tmp/wine/ /dev/hda6 -> /tmp then all works as desired. Now this is only a *workaround* and it only works for some mount points... the case making / your z: drive is an obvious example that can't be easily solved in this way. This is a case of regression... this used to work fine and now doesn't. It also means that the treatment of the drives is different in wine depending on whether they are listed in fstab or not... that doesn't seem to be logical. -- 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.

1 0

[Bug 2017] Photoshop 7.0 no longer works
by Wine Bugs July 13, 2004

July 13, 2004

http://bugs.winehq.org/show_bug.cgi?id=2017 ------- Additional Comments From drew(a)corrupt.co.nz 2004-12-07 22:27 ------- This is also an issue on Wine on FreeBSD: wine -v > Wine 20040505 This is with Synchronise=Y in the .wine/config file: drew(a)taz:~/.wine/c/Program Files/Adobe/Photoshop 7.0 [15:20:45] -> wine "C:\\Program Files\\Adobe\\Photoshop 7.0\\Photoshop.exe" fixme:ntdll:NtQueryVolumeInformationFile device info not properly supported on this platform fixme:file:get_default_drive_device auto detection of DOS devices not supported on this platform fixme:sync:SetCriticalSectionSpinCount critsection=0x20d598e0: spincount=20 not supported fixme:sync:SetCriticalSectionSpinCount critsection=0x20d59fa4: spincount=500 not supported fixme:sync:SetCriticalSectionSpinCount critsection=0x20d59aa4: spincount=500 not supported fixme:sync:SetCriticalSectionSpinCount critsection=0x20d59ca4: spincount=500 not supported fixme:sync:SetCriticalSectionSpinCount critsection=0x20d5a028: spincount=500 not supported fixme:sync:SetCriticalSectionSpinCount critsection=0x20d5a14c: spincount=500 not supported fixme:sync:SetCriticalSectionSpinCount critsection=0x20d5a1c8: spincount=50 not supported fixme:actctx:QueryActCtxW stub! fixme:actctx:QueryActCtxW stub! fixme:actctx:QueryActCtxW stub! fixme:actctx:QueryActCtxW stub! fixme:actctx:QueryActCtxW stub! fixme:actctx:QueryActCtxW stub! -- 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.

1 0

[Bug 1876] Selfloading Exe causes " ... Win16Mutex" wait timed
by Wine Bugs July 13, 2004

July 13, 2004

http://bugs.winehq.org/show_bug.cgi?id=1876 jos(a)wolput.demon.nl changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jos(a)wolput.demon.nl ------- Additional Comments From jos(a)wolput.demon.nl 2004-12-07 21:43 ------- Comment by Jos van Wolput: Trying to run the selfloading exe multilanguage dictionary euroglot with wine version 20040615-1 or 20040505-1 I always get the error mentioned below: err:ntdll:RtlpWaitForCriticalSection section 0x40568420 "syslevel.c: Win16Mutex" wait timed out in thread 0009, blocked by 000a, retrying (60 sec) Wine failed with return code 148 Using wine version 20040309 (and previous versions) it just runs fine! -- 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.

1 0

[Bug 2356] HD reported as device when mountpoint matches logical link in dosdevices
by Wine Bugs July 12, 2004

July 12, 2004

http://bugs.winehq.org/show_bug.cgi?id=2356 ------- Additional Comments From klaus.piemont(a)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 -- 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.

1 0

[Bug 2356] HD reported as device when mountpoint matches logical link in dosdevices
by Wine Bugs July 12, 2004

July 12, 2004

http://bugs.winehq.org/show_bug.cgi?id=2356 ------- Additional Comments From rklazes(a)xs4all.nl 2004-12-07 12:19 ------- > Sorry, but I can't see your point in my case. > You are correct if we speak of of a CD-ROM or Floppy. > I could maybe even accept this for a FAT or NTFS partition, but I cannot > understand what a windows app should do with a ReiserFS formated partition ? 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. ). > Especially when that partition is already mounted and it is not even user > mountable. Obviously linux doesn't allow it anyway resulting in the error code > c0000022. I was thinking it was the RW permissions of /dev/hdb5 . > In this case wine can clearly assume that the drive letter was intended to > describe a "logical" wine HD rather than a device or volume. 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. 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. Perhaps something is possible with the dosdevices/l:: link that points to the device if it exists. Did you happen to notice what the CreateFile() returns and what the LastError() was in those cases? -- 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.

1 0

[Bug 2356] HD reported as device when mountpoint matches logical link in dosdevices
by Wine Bugs July 12, 2004

July 12, 2004

http://bugs.winehq.org/show_bug.cgi?id=2356 ------- Additional Comments From klaus.piemont(a)gmx.de 2004-12-07 10:43 ------- Sorry, but I can't see your point in my case. You are correct if we speak of of a CD-ROM or Floppy. I could maybe even accept this for a FAT or NTFS partition, but I cannot understand what a windows app should do with a ReiserFS formated partition ? Especially when that partition is already mounted and it is not even user mountable. Obviously linux doesn't allow it anyway resulting in the error code c0000022. In this case wine can clearly assume that the drive letter was intended to describe a "logical" wine HD rather than a device or volume. -- 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.

1 0

[Bug 2347] no char for keysym 0000 (No Name) (in Tribes2 v24834)
by Wine Bugs July 12, 2004

July 12, 2004

http://bugs.winehq.org/show_bug.cgi?id=2347 ------- Additional Comments From lindevel(a)gmx.net 2004-12-07 07:48 ------- I think something prevents tribes2 from being run. I do not know what it is, but it was the only "err"or reported... Now I have made a complete log (WINEDEBUG=all). I you want to have some additional information, please tell me. (If you want a trace, please tell me how to do that, I tried, but failed :( ) --- WINE: 20040615 --- Information (LOGs etc.): http://home.arcor.de/bashork/gentoo/wine-tribes2/ -- 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.

1 0

[Bug 2356] HD reported as device when mountpoint matches logical link in dosdevices
by Wine Bugs July 12, 2004

July 12, 2004

http://bugs.winehq.org/show_bug.cgi?id=2356 ------- Additional Comments From rklazes(a)xs4all.nl 2004-12-07 04:54 ------- warn:file:CreateFileW Unable to create file L"\\\\.\\L:" (status c0000022) I followed this problem back to dlls/ntdll/directory.c and found that L: is resolved to /dev/hdb5 raising the invalid access. In Windows the filename "\\\\.\\L:" for CreateFile means the volume that, when opened, can be accessed as a device. Please look it up on msdn.microsoft.com. What Wine is doing here seems to be correct to me. -- 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.

1 0