Persistent unique Volume ID

Hi All,

I’m trying to get unique volume ID that will still remain valid even after system restart. I’ve got a potentially large number of log entries, each of which is associated with a particular volume. The information in a log entry needs to be persistent across reboot and requires a small size volume ID (preferably 16- or 32-bit) to minimize the log size.

The only way I could think of is to grab all persistent volume names (i.e. ??\Volume{41479d12-134f-11de-b425-005056c00008}) and assign them to 16- or 32-bit index numbers. I’m pretty sure it would work. But is there any easier way to map volumes to small-size volume IDs?

Thanks a lot.

Sean

Calc md5 of volume GUID?

Regards
Haibo

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, May 14, 2009 4:37 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Persistent unique Volume ID

Hi All,

I’m trying to get unique volume ID that will still remain valid even after
system restart. I’ve got a potentially large number of log entries, each of
which is associated with a particular volume. The information in a log entry
needs to be persistent across reboot and requires a small size volume ID
(preferably 16- or 32-bit) to minimize the log size.

The only way I could think of is to grab all persistent volume names (i.e.
??\Volume{41479d12-134f-11de-b425-005056c00008}) and assign them to 16- or
32-bit index numbers. I’m pretty sure it would work. But is there any easier
way to map volumes to small-size volume IDs?

Thanks a lot.

Sean


NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Hi Haibo,

MD5 sum is 4 DWORDs = 128bits, which is too big for my purpose and isn’t quite worth doing for my project.

Thanks.

Then you can xor every DWORD of GUID to generate a 4 bytes signature.

Regards
Haibo

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, May 14, 2009 10:47 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Persistent unique Volume ID

Hi Haibo,

MD5 sum is 4 DWORDs = 128bits, which is too big for my purpose and isn’t
quite worth doing for my project.

Thanks.


NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

>The information in a log entry needs to be persistent across reboot and >requires a small size volume ID (preferably 16- or 32-bit) to minimize the >log size.

I think you can use ZwQueryVolumeInformationFile/ FltQueryVolumeInformationFile with FileFsVolumeInformation class. You can use the VolumeSerialNumber field of the returned structure. That is a 32 bit value.

Regards,
Ayush Gupta
http://www.linkedin.com/in/guptaayush

Explore and discover exciting holidays and getaways with Yahoo! India Travel http://in.travel.yahoo.com/

> The only way I could think of is to grab all persistent volume names (i.e. ??\Volume{41479d12-134f-

Do you need to support external re-connectable disks like USB enclosures?


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Yes Maxim,

It has to support any hard drive including USB drive. The algorithm I’m thinking of is:

VolumeNameMappingTable management:

  1. OnFilterInstanceSetUp()
    InstanceSetUp stores both “my” volume id and the actual volume name (i.e. ??\Volume{41479d12-134f-11de-b425-005056c00008}) in filter instance context. InstanceSetUp() will either SetMyVolumeId() on VolumeNameMappingTable, if the volume is not already there in VolumeNameMappingTable , or GetMyVolumeId() if the volume is found in VolumeNameMappingTable.
  2. OnLogEvent()
    Log processing routine will call this function. It will simply grab my volume id from filter instance context. (filter instance context can be retrieved for every log event)
  3. OnSystemShutdown()
    Saves VolumeNameMappingTable to a file
  4. OnSystemStartup()
    Constructs in-memory VolumeNameMappingTable from the file

It’s a boring and time-consuming task. That’s why I was asking for an “easier” way assuming this algorithm would work for any disk drive including USB.

Is my assumption correct, Maxim?

Thanks in advance.

Regards,
Sean