Re: [boost] equivalent paths

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2003-12-02 10:22:07

Beman Dawes <bdawes_at_[hidden]> writes:

> At 02:44 PM 12/1/2003, Jeremy Maitin-Shepard wrote:
>>>> bool equivalent(path const &lhs, path const &rhs);

>> This function is undeniably useful, and so the fact that it does not
>> work in some obscure cases on a single platform does not seem like
>> sufficient reason not to provide it.

> I don't consider non-NTFS file systems on Windows obscure. I just bought one of
> those cute little USB Flash Drives. It uses FAT. CD's and DVD's use
> ISO-9660/Juliet. Network shares are hardly "obscure" either.

My impression from your previous message was that only in a few cases
did the system I am using fail.  Now I can see that you are actually
suggesting that it fails in all or most cases on non-NTFS filesystems.
Do you mean that the id numbers in BY_HANDLE_FILE_INFORMATION will be
completely unreliable, in that equality to those in the information for
another file will be completely unrelated to the file equivalence on
certain file systems, like iso9660 or FAT or (any) network filesystem,
or simply that it won't show hard linked files to be equivalent?  (Or
possibly in the case of network filesystems, that paths accessing the
same network file using different `share hierarchies' to access it do
not show as equal.)

If the latter is the case, it seems like less of a problem, since
neither FAT nor iso9660 can handle hard links.  Furthermore, I don't
think it is too unreasonable for hard links on a network filesystem
(which are relatively rare, I would imagine, for Windows users) do not
show as being equivalent.  

If the former is the case, then I agree it is a more serious problem,
but it seems that by using information about "mount points" i.e. drive
letters, `NTFS mount points,' and resolving `junctions,' normalized
paths can be compared.

[snip]

>> On FAT filesystems or
>> other Windows filesystems that do not support hard links, this function
>> can be implemented simply by comparing the normalized path names.

> No it can't. The problem is far wider than issues raised by POSIX-style hard or
> symbolic links. Network shares or other forms of aliases also cause comparing
> normalized path names to fail. Since Windows symbolic links are application
> features, the format isn't even necessarily known by the Boost.Filesystem
> library implementation.

As far as comparing by normalized paths, see above.  If by ``Windows
symbolic links'' you mean .lnk files, I would recommend that
boost.filesystem not treat them as symbolic links because they differ
in a number of important ways from POSIX symbolic links, and are
generally not treated by other applications as symbolic links:
specifically, they must end in a .lnk extension, and they are always
`visibly' resolved to the user.

>> If necessary, extensive filesystem-type checks could be added to the
>> Windows implementation in order to work around these few cases.

> I don't think that can be done reliably:-(

I think it can be done reasonably reliably.  Unfortunately, I have only
limited access to Windows machines, so my testing of any approach will
be difficult, but I will see what I can come up with.

-- 
Jeremy Maitin-Shepard