Re: [boost] equivalent paths

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-12-03 12:58:30

At 10:59 PM 12/2/2003, Jeremy Maitin-Shepard wrote:

 >The source to a test program is attached.

Thanks! That's very helpful!

 >...
 >
 >On Linux, testing using stat reveals that bind mounted filesystems are
 >not a problem (files on a bind-mounted filesystem are equivalent to the
 >corresponding file on the non-bind-mounted filesystem).  I believe that
 >NFS shares will not be a problem as far as hard links.  The same remote
 >file/directory accessed through two different NFS mounts has a
 >different device id depending on the mount, and therefore does not show
 >as equivalent.  This behavior does not seem unreasonable.  Samba shares
 >have the same issue with device ids, and also there is the issue that
 >DOS 8.3 paths do not show as equivalent to the long-name path.

While those cases may be unfortunate, my intuition is that false negatives 
are not as serious as false positives. Also, cases such as you mention that 
can be documented in advance are less serious that unexpected or 
undocumented mistaken results.

 >On Windows, "substitution" mounts do not pose a problem for testing
 >using the GetFileInformationByHandle.  Neither do DOS 8.3 file names.
 >(i.e. a DOS 8.3 path compares equivalent to the full-length path) DOS
 >8.3 paths do not appear to be equivalent to the full-length path on
 >network shares.  These tests were performed on a FAT32 filesystem on a
 >computer with the Windows ME operating system.  Presumably, this
 >platform is one of the more limited ones, but it would certainly be
 >better to have more complete test data from someone with more Windows
 >operating system machines available.
 >
 >You can test any additional cases about which you are concerned.

I was able to confirm your results on Win XP, except that full-paths 
against 8.3 paths did work OK across network shares. Presumably that was 
because I was running later Windows versions than you were. I also tried 
various cases on CD and Flash Drive file systems, and they all worked 
correctly, as did a case using hard links.

The one incorrect result came with floppies. I had modified your program to 
print out dwVolumeSerialNumber and the indexes, and I noticed on a floppy 
test that dwVolumeSerialNumber was 0. I then took two new floppies, and 
copied the same file to both. I put one in my local machine, and the other 
in a networked shared floppy drive on another machine. They compared 
equivalent!

The really odd thing is that dwVolumeSerialNumber was not 0, although it 
was the same for both diskettes. I don't know what to make of that, but my 
initial reaction is that it isn't a showstopper. Be better if we could 
understand a bit better what is happening.

One case that doesn't work at all is directories. The error messages are:

error with path: d:\temp
error code: 5
error message: Access is denied.

Do you see any workaround for that?

Thanks again for the test program,

--Beman