https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #4 from Erich E. Hoover erich.e.hoover@gmail.com --- (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
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).