Re: [boost] equivalent paths

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-12-03 16:23:51

At 01:44 PM 12/3/2003, Jeremy Maitin-Shepard wrote:

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

"dwVolumeSerialNumber" seems to be reported correctly, even across network 
shares and FAT file systems. The problem has to do with floppy formatting. 
See below.

 >It seems the dwVolumeSerialNumber it is returning may be obtained from
 >some serial number generated when the filesystem was created on the
 >diskette.

Yes, exactly. The dwVolumeSerialNumber seems to be [re]assigned whenever 
the floppy is hard formatted.

Based on experiments I just ran, the floppy format function in Win XP 
assigns a new, apparently random, volume serial number every time the disk 
is formatted. That same volume serial number is reported by 
dwVolumeSerialNumber regardless of whether the floppy is being read locally 
or across a network share. It makes sense when you think about it. The 
volume serial number never changes as long as the diskette isn't hard 
formatted. Come to think about it, the IBM OS/360 used the same volume 
serial number scheme thirty-five years ago.

The floppy tests I ran this morning happened to use two brand-new diskettes 
from the same package. It looks like the formatter used by the manufacturer 
(Office Max store brand) didn't bother to assign a new volume serial 
number. So the bottom line is your code is OK, and so is Win XP. A warning 
in the docs about floppies would be in order, but that should be 
sufficient.

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

Yep, it could have been permission or other problems. I did change the code 
to no longer ask for write access, but might have goofed that up somehow.

I'm going to be travelling until Saturday, so won't be able to run any more 
tests until next week.

Thanks,

--Beman