[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 #42 from Zebediah Figura <z.figura12 at gmail.com> ---
(In reply to Erich E. Hoover from comment #41)
> > 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.

I think not using realpath() is absolutely required. We'd still have to
manually resolve the real path for non-Unix symlinks, though.

But here are the other problems:

* What does GetVolumePathName() on a cross-device Unix symlink return? I'm not
even necessarily thinking about file IDs here—we can fit st_dev + st_ino into a
16-byte file ID if we have to—but rather:

* do we report that two files are on the same device when they aren't actually?
Would it break an application that suddenly can't cope when renaming the file
fails?

* What if you then pass that name to other volume functions? If
GetVolumePathName() returns the symlink, how does kernelbase determine the
actual mount point? If it returns the C: drive for every file, then we lie to
the application about aspects of the file system—say, the amount of free space
left.

* If we punt and pretend that there's only ever one file system—what about
removable devices? Do we apply a heuristic and always expose cross-device host
symlinks to removable devices, but not otherwise?


Maybe there's an argument for hiding host symlinks only in the same-device
case. On the other hand, I'm inclined to say that some applications are broken,
and in that case the user will just have to work around that by not using
symlinks. How many applications are actually affected by such symlink bugs is
of course difficult or impossible to guess, but at least we haven't seen *that*
many come up yet, not in wine-staging...

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