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
"dwVolumeSerialNumber" seems to be reported correctly, even across network
shares and FAT file systems. The problem has to do with floppy formatting.
>It seems the dwVolumeSerialNumber it is returning may be obtained from
>some serial number generated when the filesystem was created on the
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
>>> One case that doesn't work at all is directories. The error messages
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk