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.