[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 #10 from Erich E. Hoover <erich.e.hoover at gmail.com> ---
(In reply to Hans Leidekker from comment #8)
> (In reply to Erich E. Hoover from comment #7)
> > ...
> > 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.

I've actually put together a little tech demo on completely transparent
symlinks to reduce the size of the prefix by using symlinks for the fake/real
dlls.  It would not be too difficult for me to modify this to look for "no
recognized tag" instead of "special Wine tag".  I can probably do that this
weekend if you think that's worth it.

(In reply to Zebediah Figura from comment #9)
> Note that a symlink can span file systems. It seems possible that a Windows
> application would be confused about a file residing on a different file
> system than its containing directory. That's already the case, and maybe not
> worth worrying about, but if we're going to make a grand final design of how
> symlinks work it might be worth taking into account...

Are you talking about applications that look for files based on inode?  We
could conceivably report the inode of the symlink in the case of a transparent
symlink like this (and this is a feature that wouldn't be too hard to add in
the future).

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