https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #5 from Arnaud Dovi mr.dovi@gmail.com --- (In reply to Erich E. Hoover from comment #4)
(In reply to Arnaud Dovi from comment #1)
I had removed the commands from OP for readability but basically I have done 2 testcase per wine version, one on a symlink directory and another one on a real directory
wine_file c:\symlink wine_file c:\windows
To note that wine-staging-6.0 returns 0 with real directories so it seems to only affect symlinks.
Okay, before I back out and test the old patches I have a question: what kind of symlink are you using? There are four types (at the moment):
- junction point
- unix symlink
- relative directory symlink
- absolute directory symlink
Wasn't aware there was 4 different one, the one I used is what I think is 2) unix symlink, created with ln -s on a directory. I also know the MKLINK.exe method but this one does not ships with wine so they are probably only creatable programmatically.
examples:
c:>dir Volume in drive c has no label. Volume Serial Number is 0000-0000
Directory of c:\
1/30/2021 12:55 PM <JUNCTION> junction [C:\windows] 1/30/2021 12:55 PM <SYMLINKD> symlink 1/30/2021 12:55 PM <SYMLINKD> symlinkd [windows] 1/30/2021 12:55 PM <SYMLINKD> symlinkdabs [C:\windows] ... ===
With your program I see:
- c:\junction:
pNtCreateFile -> 0 NtQueryInformationFile -> 0
- c:\symlink:
pNtCreateFile -> 0 NtQueryInformationFile -> c0000003
- c:\symlinkd:
pNtCreateFile -> 0 NtQueryInformationFile -> 0
- c:\symlinkdabs:
pNtCreateFile -> 0 NtQueryInformationFile -> 0
So, I suspect that this problem only extends to "unix symlinks" - which I have not decided how to treat "properly" yet. My current inclination is to convert them into Z:\ paths, but that may have weird consequences. If this is actually the problem for you, what was happening before? It's been a while since I made the updates for 6.0, but I think that before then it reported by-handle requests as the information for the destination folder (didn't show up as a symlink).
I think in the startup log OK I have the link is converted to Z
On logs side by side the break happens here on staging-6.0
trace:file:nt_to_unix_file_name_internal L"\??\C:\Program Files\Black Tree Gaming Ltd\Vortex" -> "/home/arno/.local/share/Steam/steamapps/compatdata/2260996941/pfx/dosdevices/c:/Program Files/Black Tree Gaming Ltd/Vortex" create_file( access=00100080, sharing=00000007, create=1, options=00204020, attrs=00000000, objattr={rootdir=0000,attributes=00000040,sd={},name=L""}, filename="/home/arno/.local/share/Steam/steamapps/compatdata/2260996941/pfx/dosdevices/c:/Program Files/Black Tree Gaming Ltd/Vortex" ) create_file() = 0 { handle=0240 } Ret ntdll.NtCreateFile() retval=00000000 ret=7b016bea Call ntdll.RtlFreeUnicodeString(0021d180) ret=7b016fdd Ret ntdll.RtlFreeUnicodeString() retval=00000001 ret=7b016fdd trace:file:CreateFileW returning 0000000000000240 Ret KERNEL32.CreateFileW() retval=00000240 ret=142ee27b1 Call ntdll.NtQueryInformationFile(00000240,0021d360,0021d388,00000068,00000012) ret=142ee6ddb trace:file:NtQueryInformationFile (0x240,0x21d360,0x21d388,0x00000068,0x00000012) get_handle_fd( handle=0240 ) *fd* 0240 -> 296 get_handle_fd() = 0 { type=2, cacheable=1, access=00100080, options=00204020 } Ret ntdll.NtQueryInformationFile() retval=c0000003 ret=142ee6ddb Call KERNEL32.GetLastError() ret=142ee27d9 Ret KERNEL32.GetLastError() retval=00000057 ret=142ee27d9
while one staging-5.21 this seem to resolve to Z:
trace:file:nt_to_unix_file_name_internal L"\??\C:\Program Files\Black Tree Gaming Ltd\Vortex" -> "/home/arno/.local/share/Steam/steamapps/compatdata/2260996941/pfx/dosdevices/c:/Program Files/Black Tree Gaming Ltd/Vortex" create_file( access=00100080, sharing=00000007, create=1, options=00004020, attrs=00000000, objattr={rootdir=0000,attributes=00000040,sd={},name=L""}, filename="/home/arno/.local/share/Steam/steamapps/compatdata/2260996941/pfx/dosdevices/c:/Program Files/Black Tree Gaming Ltd/Vortex" ) create_file() = 0 { handle=0218 } Ret ntdll.NtCreateFile() retval=00000000 ret=7b016a31 Call ntdll.RtlFreeUnicodeString(0021d1d0) ret=7b016ed5 Ret ntdll.RtlFreeUnicodeString() retval=00000001 ret=7b016ed5 trace:file:CreateFileW returning 0000000000000218 Ret KERNEL32.CreateFileW() retval=00000218 ret=142ee27b1 Call ntdll.NtQueryInformationFile(00000218,0021d360,0021d388,00000068,00000012) ret=142ee6ddb trace:file:NtQueryInformationFile (0x218,0x21d360,0x21d388,0x00000068,0x00000012) get_handle_fd( handle=0218 ) *fd* 0218 -> 324 get_handle_fd() = 0 { type=2, cacheable=1, access=00100080, options=00004020 } get_handle_unix_name( handle=0218, nofollow=0 ) get_handle_unix_name() = 0 { name_len=65, name="/home/arno/.local/share/Steam/steamapps/common/Vortex Mod Manager" } trace:file:find_drive_rootA "/home/arno/.local/share/Steam/steamapps/common/Vortex Mod Manager" -> drive Z:, root="/", name="/home/arno/.local/share/Steam/steamapps/common/Vortex Mod Manager"
To note that in some part of the staging-6.0 failing log, NtQueryInformationFile returns OK and the link is resolved if the options in create_file is 00004020 not 00204020 (FILE_OPEN_REPARSE_POINT removed)