[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 #46 from Zebediah Figura <z.figura12 at gmail.com> ---
I think there may be some confusion. Currently the situation in upstream wine
is:

* NtQueryAttributesFile() reports FILE_ATTRIBUTE_REPARSE_POINT for directory
symlinks, regardless of whether FILE_OPEN_REPARSE_POINT is specified.

* FILE_OPEN_REPARSE_POINT never opens the symlink for NtCreateFile/NtOpenFile.

* FSCTL_*_REPARSE_POINT is not supported on symlinks.

* ObjectNameInformation and similar APIs report the resolved path for both file
and directory symlinks.

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

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? If an
application passes FILE_OPEN_REPARSE_POINT or uses FSCTL codes, shouldn't it
already know how to deal with the results?

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

But yeah, we can't easily lie about that, because GetVolumePathName() needs it.

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