Re: [boost] equivalent paths

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2003-12-03 13:44:15

Beman Dawes <bdawes_at_[hidden]> writes:

[snip]

> 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.

I agree.

[snip]

> 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!

I wonder if a better volume id can be obtained from the _stat function
provided in the API.  It may be the case that the
"dwVolumeSerialNumber" is not handled correctly by Windows for network
shares.  It seems possible that the local volume id is the same one
returned when this volume is accessed over a network share.  A possible
workaround is to detect network paths, and always return `different' if
the networked paths are each on different hosts, or one is a local path
and the other a network path.

> 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.

It seems the dwVolumeSerialNumber it is returning may be obtained from
some serial number generated when the filesystem was created on the
diskette.  When Windows copies the diskette, it might be imaging the
disk, and thus copy the stored serial number also.

> 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?

I suppose it would be good to figure out which API call is failing --
it seems I forgot to add code to print "what" in "print_error."  The
documentation indicates that CreateFile can open a directory (but only
on Windows NT).  Thus, I would not expect CreateFile to fail, although
it is possible that the sharing modes are a problem.  The documentation
for BY_HANDLE_FILE_INFORMATION would suggest that
GetFileInformationByHandle can be used on directory handles.  If it
cannot though, some other approach will be needed.

-- 
Jeremy Maitin-Shepard