[boost] equivalent paths [was: Hard link support for boost.filesystem]

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