Re: [boost] [filesystem] adding path equality and path equivalence

From: John Maddock (john_at_[hidden])
Date: 2004-02-01 11:46:18

> Equivalence
> -----------
>
> Two paths will be considered equivalent if they resolve to the same
> physical directory or file.
>
> Question 1: What is a use case that requires this function? Verifying that
> source and target files are different before some modifying operation is
> the only one I've come up with. I guess that is sufficient to justify
> adding the function.

I have another: if you are walking a directory tree and following links,
then you need to be able to detect whether two directories are the same in
order to prevent infinite recursion, caused by cyclic directory graphs.

> Question 2: What if neither exist? Only one exists? My initial thought is
> that these are likely to be errors, so treat them as such. It could be
> argued that if either or both don't exist, they can't be equivalent, so
> return false.

If only one exists, it's not an error, the two are necessarily
non-equivalent.  If neither exists, you have a problem ;-)  Probably an
error, unless someone has a compelling use case.

> Question 3: The implementation on Windows (see below) leaves a small hole
> in that duplicated media (such as two CD's) mounted on devices with the
> same device id on two different networked machines would be reported as
> equivalent. POSIX requires that such networked devices have different
> device id's, avoiding the problem. Is the fact that Windows and POSIX
> implementations would perform slightly differently on this corner case a
> showstopper? I think not.
>
> Windows logic for path equivalent: same device id AND same media volume
> serial number AND same physical location on disk AND same creation time.
> This works even in degenerate cases like camera formatted FAT flash memory
> cards or floppy disks with volume serial numbers incorrectly initialized
to
> 0.
>
> POSIX logic: same device id AND same physical location on disk AND same
> modification time. The modification time is in theory redundant, but is an
> added protection in case the device id on networked devices failed to meet
> the POSIX specs.

Wow, I'm impressed, that looks good to me though.

John.