[Bug 50586] NtQueryInformationFile returns STATUS_INVALID_INFO_CLASS on symlinks opened with FILE_OPEN_REPARSE_POINT

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50586

--- Comment #5 from Arnaud Dovi <mr.dovi at 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):
> 1) junction point
> 2) unix symlink
> 3) relative directory symlink
> 4) 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)

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.