[Bug 50586] NtQueryInformationFile returns STATUS_INVALID_INFO_CLASS on symlinks opened with FILE_OPEN_REPARSE_POINT

WineHQ Bugzilla wine-bugs at winehq.org
Tue Feb 2 10:47:28 CST 2021


https://bugs.winehq.org/show_bug.cgi?id=50586

--- Comment #16 from Erich E. Hoover <erich.e.hoover at gmail.com> ---
(In reply to Zebediah Figura from comment #15)
> (In reply to Hans Leidekker from comment #14)
> > ...
> > If cross-device *directory* unix symlinks where NT symlinks but not
> > cross-device *file* unix symlinks then I think you could end up with
> > inconsistencies. E.g. GetVolumePathName would report different volumes for a
> > file and its parent directory if the file is a symlink to a third filesystem.
> 
> I'm not sure I understand. If we pretend that cross-device file symlinks
> aren't symlinks, then a file will always report the same device as its
> containing directory, won't it?
> ...

If I'm understanding correctly, we're talking about (in the context of unix
symlinks):
1) reporting file symlinks transparently (no evidence to the Windows program
that they exist)
2) reporting file symlinks using the inode number of the symlink rather than
the target so that inode searches work correctly
3) reporting directory symlinks as an NT directory symlink (0xA000000C)


So, due to #2 combined with #3, GetVolumePathName will always see that a file
symlink is on the same device as the parent directory and if that directory is
on a different device than its parent then it may report that directory as the
start of the volume.  Example:
C:\myfolder -> D:\myfolder
D:\myfolder\myfile -> E:\myfile
GetVolumePathName(C:\myfolder\myfile) would give C:\myfolder, where C:\myfolder
reports the target inode on D:\ and C:\myfolder\myfile reports the symlink
inode on D:\.

If i'm understanding correctly then this sounds reasonable to me, if a little
complicated to implement.  My inclination would be start by making unix
symlinks act as similar as possible to how they do in non-staging now
(transparently report all information about the target, regardless of being for
a file or a directory) and then add this complexity on from there once I'm sure
nothing is broken.  How does that sound to everyone?

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



More information about the wine-bugs mailing list