From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-12-01 21:55:19
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.
> (On the contrary, this seems like
>something that should be fixed in Windows NT.)
Sure. But I'm not holding my breath. Seriously, one reason that libraries
which depend on native API's are so difficult is that we just have to
accept the native API's as givens, even though they may be pretty
deficient.
> 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.
>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:-(
--Beman