[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 #15 from Zebediah Figura <z.figura12 at gmail.com> ---
(In reply to Hans Leidekker from comment #14)
> (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'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?

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

I don't think that's enough, though, is it? FileInternalInformation is only 64
bits. Or is it okay for that to not be unique?

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