[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 #28 from Erich E. Hoover <erich.e.hoover at gmail.com> ---
(In reply to Arnaud Dovi from comment #27)
> ...
> One thing I'm unsure yet is how a vanilla wine reacts to this situation with
> symlink made with MKLINK, maybe it is an issue upstream on wine ?

The staging mklink creates a "specially-formatted" unix symlink that upstream
wine just treats like any regular unix symlink.  You can see this if you do a
listing on the file vs. running realpath:
$ ls -haltr ~/.wine/drive_c/symlink
lrwxrwxrwx 1 ehoover ehoover 80 Feb  5 11:02
/home/ehoover/.wine/drive_c/symlink ->
///././/////////////////////////.//././/home/ehoover/.wine/dosdevices/c:/windows
$ realpath ~/.wine/drive_c/symlink
/home/ehoover/.wine/drive_c/windows

> Anyway don't worry about helping me fixing the issue, I think I have found a
> better way to match how Steam proton actually works.
> ...
> But if this issue lies on staging I hope a good test case for you to fix
> this issue that should be difficult to work on.

Yeah, I am concerned that there is a deficiency of some kind in my NT symlink
support if this is causing issues for you.  I would expect that an application
that is aware of NT symlinks (which this appears to be) would behave correctly
in the described scenario.  Would you mind running the application with
WINEDEBUG="+volume" to see if it is calling GetVolumePathName and doing
something strange with the results?

-- 
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.