Re: [boost] equivalent paths

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-12-02 17:17:42

At 10:22 AM 12/2/2003, Jeremy Maitin-Shepard wrote:

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

Yes, that's what I'm afraid of.

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

I'm most worried about the former case.

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

Here are some of the specific cases I'm worried about, particularly on 
non-NTFS filesystems:

   C:\Program Files\foo.tst
   C:\PROGRA~1\FOO.TST
   \\ACOMPUTER\Share1\FOO.TST
   \\ACOMPUTER\Another Share\FOO.TST
   p:\foo.tst

That last case occurs after a command "subst p: C:\PROGRA~1" has been 
given.

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

If you put something together, I can test it here. A little command line 
program that takes two paths, and returns "same" or "different" would be 
easy to test.

Incidentally, I'm not worried about older versions of Windows. Win 2K and 
Win XP are the most serious concerns.

I'm also concerned about POSIX corner cases. I'm not sure what they may be, 
but mounted filesystems, samba, etc, might be starting places to test.

--Beman