[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 #14 from Hans Leidekker <hans at meelstraat.net> ---
(In reply to Zebediah Figura from comment #13)
> (In reply to Erich E. Hoover from comment #12)
> > Yeah, I'm not sure what we could possibly do to properly support a
> > cross-device directory unix symlink if someone's searching the disk by
> > inode.  If we treated them as NT symlinks then any application doing this is
> > _supposed_ to use GetVolumePathName to search the correct volume.
> 
> Right, and that actually works. It's not clear to me if there are any
> problems that result from this (well, I've seen a couple applications not
> know what a Windows mounted folder is, but that can probably be fixed by
> always automatically creating a drive for any mount point). But I'm probably
> missing something.

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 guess you are referring to file ids being 128-bit and directory ids 64-bit?
So we could include st_dev in file ids to make them unique across filesystems,
but there's no such option for directory ids.

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