[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 #19 from Erich E. Hoover <erich.e.hoover at gmail.com> ---
(In reply to Zebediah Figura from comment #18)
> ...
> 
> (1) How much of a problem is it really to report Unix symlinks as win32
> symlinks? (Does the wine-staging patch already do this?) It could
> potentially be simpler.

Not much, it's really just modifying the current patch to detect that the
symlink is not Wine-created and convert the Unix path into an NT path.  The
concern about doing this would be for old applications, that don't have reparse
point support, accessing unix symlinks.  This isn't just user-created unix
symlinks though, Wine creates unix symlinks for several special directories
(Desktop, My Documents, etc.), so this matters even in a fresh prefix.

> Note also that we need to treat system DLLs
> specially anyway, to get copy-on-write behaviour.

Right.  While I haven't implemented that in the tech demo I gave you, that's
part of why it uses a custom reparse tag.  You almost certainly wouldn't want
to do that with regular unix symlinks though.

> (2) On the other hand, if there is a good reason to hide Unix symlinks, does
> it make sense to also hide same-device Unix directory symlinks?

Conceivably we could hide all same-device symlinks and report cross-device unix
symlinks as NT symlinks (whether they're a directory or not).  But we may be
spending a lot of effort thinking about something that's not really a big deal,
do you know if we have any bugs reported for issues like this?

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