How do you read the 128-bit NTFS FILE_ID for a directory and / or file?

So NTFS uses 128-bit Guid to identify files and directories, you can easily view this information:

  C: \ Temp> C: \ Windows \ System32 \ fsutil.exe objectid query.
 Object ID: ab3ffba83c67df118130e0cb4e9d4076
 BirthVolume ID: ca38ec6abfe0ca4baa9b54a543fdd84f
 BirthObjectId ID: ab3ffba83c67df118130e0cb4e9d4076
 Domain ID: 00000000000000000000000000000000

So, this is fairly obvious, but how to get this information programmatically? Looking at WinApi for OpenFileById (...), you can get this information. One would expect this to be done in the Win32 FileID API Library , but the method ( GetFileInformationByHandleEx ) returns the FILE_ID_BOTH_DIR_INFO structure. This structure defines FileId; however, this is LARGE_INTEGER (64 bits), not a full 128-bit identifier.

I guess you can use WMI for this, this is where should I turn?

+6
source share
2 answers

DeviceIoControl me a little in DeviceIoControl , and the answer to your question: FSCTL_GET_OBJECT_ID returns exactly the same identifiers as on your output from fsutil .

In any case, the documents for BY_HANDLE_FILE_INFORMATION say that the 64-bit file identifier already uniquely identifies the file on this volume. According to Wikipedia , NTFS only supports a maximum of 2 ^ 32 files, so a 128-bit ID seems completely unnecessary.

+6
source

Also note that NOT every file has a GUID. The GUID mechanism is mainly used for .lnk files to maintain connectivity when moving the target. Only $ Volume and link file targets have these GUIDs. Alternatively, you can install them manually.

Their advantage is that the GUID should not conflict between volumes, and the file identifier should not conflict. FILE_ID is actually 48 bits of MFT_RECORD_NUMBER and 16 bits of MFT_SEQUENCE_ID

+1
source

All Articles