[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 #41 from Erich E. Hoover <erich.e.hoover at gmail.com> ---
(In reply to Zebediah Figura from comment #40)
> (In reply to Erich E. Hoover from comment #39)
> > ...
> > I'll see if I can find some time this weekend to dig out my old windows box,
> > as I can probably "put this to bed" by recreating this behavior on windows
> > with the same symlink situation.
> 
> Yeah, no problem, I've been a bit overwhelmed too...
> 
> Is the application specifically reading the symlink, or is it just using
> GetFinalPathNameByHandle() and getting the realpath? (which IIRC that
> function does give the realpath, cf. a20d8bda3). Not that it matters; the
> application is broken either way. Unfortunately this seems difficult to work
> around without aggressively trying to hide symlinks.

I didn't get around to my test this weekend, but when I get a chance I'll check
both this and what happens in the same situation on Windows.

> Problem is, we are going to run into more broken applications like this.
> Some symlink issues are easy enough to work around, but some like this are
> harder. But when I think about what would be necessary to really completely
> hide Unix directory symlinks, it just ends up feeling hacky one way or
> another; I can see it easily becoming an unmaintainable pile of workarounds.
> Maybe I'm being too paranoid, though...

Yeah, that's one of the reasons why I think it might be easier to hide unix
symlinks rather than to treat them as Windows symlinks.  Hiding them is _much_
easier than supporting them properly.  As the patches stand, there's only "two"
places that need to care:
1) server/fd.c: open_fd() would need to ignore FILE_OPEN_REPARSE_POINT on unix
symlinks (any symlink with invalid reparse tag magic)
2) dlls/ntdll/unix/file.c get_file_info() and fd_get_file_info() would need to
not report FILE_ATTRIBUTE_REPARSE_POINT for unix symlinks

The only other thing that might be required, which is not difficult, would be
to _not_ use the realpath() server/fd.c for regular unix symlinks and use a
"normalized" path instead.

> Sucks, but the best answer may be "you broke the application, you get to
> pick up the pieces" :-(

Yeah, if we try to report unix symlinks "properly" that is a very distinct
possibility.

(In reply to Arnaud Dovi from comment #38)
> If you prefer guy I will do another ticket to better track the other issue

The original issue here should be fixed by staging commit
750044c08c49c7a117fcc911506a198969379144, so yeah - we should probably open a
new issue.

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