Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

FSCTL_CREATE_OR_GET_OBJECT_ID for OpenFileById

Ask Question

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?

you confuse 2 absolute different things 8-byte file reference number for a file. (this is 48-bit index of mft record + 16-bit sequence number) and 16-byte "file object ID" (GUID). – RbMm Jun 18, 2020 at 1:19 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


    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, 2020 at 2:27 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, 2020 at 2: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, 2020 at 7:41 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, 2020 at 9:41

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question . Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers .