From: John Maddock (john_at_[hidden])
Date: 2004-02-01 11:46:18
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk