[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 #51 from Zebediah Figura <z.figura12 at gmail.com> ---
(In reply to Erich E. Hoover from comment #49)
> (In reply to Zebediah Figura from comment #48)
> > ...
> > Wait, so it *specifically* requests the resolved target path and *still*
> > treats it like it's not resolved?
> 
> This is an intermediate directory, so it _looks_ like what happens is that
> it's resolving the target of the directory and then using a relative path
> that's actually in the original location.  Something like this:
> 1) application is at c:\symlink\app.exe
> 2) c:\symlink links to x:\appdir\
> 3) application reads symlink and converts its path to x:\appdir\app.exe
> 4) application attempts to read files "up" a directory (..\myfolder\stuff)
> 5) application expects to find c:\myfolder\stuff
> 6) application fails to find it, because it's now trying to find
> x:\myfolder\stuff
> 

Yeah, okay, that seems to be exactly what you said in comment 39, so I must be
asking you to repeat yourself here. I just want to confirm that (a) the
application is specifically aware of symlinks, (b) it's trying to read the
symlink target specifically via FSCTL_GET_REPARSE_POINT, rather than querying
ObjectNameInformation or something, (c) its symlink handling code is broken and
uses the target path when it should use the source path.

That is, I want to confirm that this is a bug in an application that tries to
handle symlinks but does it incorrectly [and that it's not a bug with how we
handle symlinks in wine-staging anywhere...]

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