[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 #47 from Erich E. Hoover <erich.e.hoover at gmail.com> ---
(In reply to Zebediah Figura from comment #46)
> I think there may be some confusion.

Sorry, that's my bad.  There's a lot of different pieces to this, so I
apologize for making this difficult.

> Currently the situation in upstream
> wine is:
> ...
> I don't know of any application offhand that is actually broken by these. (I
> do know applications that are broken by GetVolumePathName() not returning a
> drive root, but that's mostly orthogonal).

Agreed.

> The question is, does "hiding all Unix symlinks" mean roughly this (probably
> while also respecting FILE_OPEN_REPARSE_POINT in NtQueryAttributesFile)?
> Respecting FILE_OPEN_REPARSE_POINT in NtQueryAttributesFile but not
> NtCreateFile? Returning the target path from ObjectNameInformation?

Roughly yes, when I say "hiding unix symlinks" I mean treating them as similar
to upstream Wine as possible.  In this case I would say that NtCreateFile with
FILE_OPEN_REPARSE_POINT would check the symlink type and, if it's not a
recognized reparse tag, ignore the FILE_OPEN_REPARSE_POINT flag. 
ObjectNameInformation would, similarly, need to return the target path.

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

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