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