[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 #48 from Zebediah Figura <z.figura12 at gmail.com> ---
(In reply to Erich E. Hoover from comment #47)
> > Based on comment 39, I'd think the part that's actually breaking *this*
> > application is the fourth bullet point, viz. that ObjectNameInformation
> > (=GetFinalPathNameByHandle) returns the resolved symlink, but I'm probably
> > missing some context (or I've already forgotten it), because I don't know
> > why that'd only break with recent symlink changes (I'd think it'd happen
> > with upstream wine too?)
> > ...
> 
> This application actually uses FSCTL_GET_REPARSE_POINT to read the reparse
> point and (sorry, I thought I reported back on this).  If the tag type is
> one of the normal ones then it interprets the path and uses that to do some
> voodoo that I have no visibility into.  If you use an unrecognized tag type
> like IO_REPARSE_TAG_LX_SYMLINK then it appears to behave normally (though I
> would appreciate if Arnaud could double check that).

Wait, so it *specifically* requests the resolved target path and *still* treats
it like it's not resolved?

Are we sure we can't just resolve this as "terminally broken application"?

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