[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 #43 from Erich E. Hoover <erich.e.hoover at gmail.com> ---
(In reply to Zebediah Figura from comment #42)
> ...
> I think not using realpath() is absolutely required. We'd still have to
> manually resolve the real path for non-Unix symlinks, though.

For NT symlinks I'm currently storing both the original/symlink path
(non-normalized) and the realpath(), if you're saying that the original/symlink
path needs to be normalized then I should probably add that to the current
patches.

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

We can easily do the same fake-out that we're doing right now with
FileAttributeTagInformation returning IO_REPARSE_TAG_MOUNT_POINT.  It's
possible here that there are applications that would be broken by this (but
they would be just as broken now), but worst case this could be replaced with a
wine-specific option or FILE_INFORMATION_CLASS.

> * 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?

Not unless we have to, since right now Wine doesn't do this with unix symlinks
and nobody seems to notice.

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

Since Wine doesn't do this right now, I would not suggest that an initial
implementation do it either.

> * 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?

I really don't think we should pretend there's only one file system.

> Maybe there's an argument for hiding host symlinks only in the same-device
> case.

I think there's a decent argument that we could start from the current Wine
position (hiding) and add complexity if it proves to be a problem.

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

Yeah, I think we are likely to find more issues now that we've started
reporting unix symlinks as NT symlinks (especially since Wine creates symlinks
for My Documents, Desktop, and Downloads).  Before we only had the possibility
of applications seeing NT symlinks from Windows applications that actually
created them in the first place.  I'd be happy to be wrong though, code-wise
reporting unix symlinks as NT symlinks is easier than hiding them ;)

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