[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 #8 from Hans Leidekker <hans at meelstraat.net> ---
(In reply to Erich E. Hoover from comment #7)
> Okay, it looks like what would have happened before (FILE_OPEN_REPARSE_POINT
> did not work correctly) was that pre-6.0 wine-staging would have followed
> the link to the target and reported information on the target.  So, I have a
> few sane ways that I can handle this that I'm considering:
> 1) treat unix symlinks as an NT symlink (0xA000000C) targeting the Z:\ or
> \??\unix path
> 2) treat unix symlinks as a custom NT reparse point ('UNIX'/0x58494E55?)
> targeting the unmodified unix path
> 3) treat unix symlinks as not being NT reparse points at all and always
> follow them to the target
> 
> I'm leaning towards option 2 to try and keep unix symlinks distinct from the
> NT symlinks and to potentially allow programs built to work with wine to
> create unix symlinks if they wish.  The downside of this option is that it's
> possible that poorly-coded Windows programs would see the unusual reparse
> tag and do something dumb.

Doesn't this argue for 3? If an app is Wine-aware there should be other ways to
create unix symlinks. I think transparent unix symlinks is a useful feature
that users may already depend on.

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