1

Recently I've stumbled upon "If you want to use GUIDs to identify your files, then nobody's stopping you" article by Raymond Chen and wanted to implement this method. But then I found that there is another way to get file ID and this is GetFileInformationByHandleEx with FILE_INFO_BY_HANDLE_CLASS::FileIdInfo and using the FileId field (128 bit).

I tried both, both methods works as expected but I have a few questions I cannot find any answers to:

  • These methods return different IDs (and the id from GetFileInformationByHandleEx seems to use only the low 64 bit leaving the high part as zero). What each of them represent? Are they essentially the same thing or just two independent mechanisms to achieve the same goal?
    • Edit: Actually I've just found some information. So the ObjectID from DeviceIoControl is NTFS object ID but what is the other ID then? How do they relate (if at all)? Are both methods available only on NTFS or at least one of them will work on FAT16/32, exFAT, etc?
  • Documentation for FILE_INFO_BY_HANDLE_CLASS::FileIdInfo doesn't tell us that the ID may not exist unlike FSCTL_CREATE_OR_GET_OBJECT_ID where I need to explicitly state that I want the ID to be created if there isn't one already. Will it have any bad consequences if I'd just blindly request creation of object IDs for any file I'll be working with?
  • I found a comment for this question that these IDs remain unchanged if a file is moved to another volume (logical or physical). I did test only the DeviceIoControl method but they indeed don't chnage across drives but if I do move the file I'm required to supply OpenFileById with the destination volume handle, otherwise it won't open the file. So, is there a way to make OpenFileById find a file without keeping the volume reference?
    • I'm thinking of enumerating all connected volumes to try to open the file by ID for each until it succeed but I'm not sure how reliable is this. Could it be that there could exist two equal IDs that reference different files on different volumes?
  • How fast it is to ask system to get (or create) an ID? Will it hurt performance if I add the ID query to regular file enumeration procedures or I'd better to do that only on demand when I really need this?
Karandra
  • 56
  • 1
  • 6
  • 1
    you confuse 2 absolute different things [*8-byte file reference number for a file.*](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_file_internal_information) (this is 48-bit index of mft record + 16-bit sequence number) and 16-byte "file object ID" (GUID). – RbMm Jun 18 '20 at 01:19
  • 1
    A file ID has to be permanent within the filesystem. FAT[32] and exFAT lack this, so they do not support `OpenByFileId`. NTFS and ReFS support real file IDs. You can get the filesystem flags via `GetVolumeInformationByHandleW` or `GetVolumeInformationW` and check for `FILE_SUPPORTS_OPEN_BY_FILE_ID`. NTFS also supports object IDs, but FAT[32], exFAT, and ReFS do not, which you can check as the flag `FILE_SUPPORTS_OBJECT_IDS`. – Eryk Sun Jun 18 '20 at 02:27
  • 1
    FYI, object IDs are primarily used by the shell for distributed link tracking. If you create a shell link to a file, it should also generate an object ID for the target file if it doesn't already have one. If you rename or move the target file and try to open the shell link, the system resolves the new location of the target file and updates the shell link. – Eryk Sun Jun 18 '20 at 02:57
  • Right, I totally forgot about `FILE_SUPPORTS_OPEN_BY_FILE_ID`/`FILE_SUPPORTS_OBJECT_IDS`. Also, this explains why the ID returned by `FILE_INFO_BY_HANDLE_CLASS::FileIdInfo` uses just half of the GUID. I'm not going to write distributed link tracking or anything, I just wanted to know how it works. – Karandra Jun 18 '20 at 07:41
  • 1
    Object IDs have to be unique across systems, so they use a 128-bit globally unique ID (GUID) as opposed to a 64-bit locally unique ID (LUID). A 64-bit LUID is enough for a file ID, since it's limited to a single filesystem. That said, ReFS uses 128-bit file IDs (with compatibily support for 64-bit file IDs). Every directory in ReFS has a 64-bit ID, from a monotonically increasing counter in the filesystem. Files created in a directory have a 64-bit relative ID based on a monotonically increasing counter for the directory, starting at index 1. The 128-bit file ID combines the two. – Eryk Sun Jun 18 '20 at 09:41
  • Thanks. That's some really useful info. – Karandra Jun 18 '20 at 10:42

0 Answers0