Issue

Public

As per the linked spec (https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/2d3333fe-fc98-4a6f-98a2-4bb805aff407):

"A 64-bit file ID value uniquely identifies a file within a given volume. This identifier is generated and stored by the file system. The identifier SHOULD be unique to the volume and stable until the file is deleted."

Definition of SHOULD (https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/8ac44452-328c-4d7b-a784-d72afd19bd9f):

"MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are used as defined in [RFC2119]. All statements of optional behavior use either MAY, SHOULD, or SHOULD NOT."

RFC 2119 (https://www.rfc-editor.org/info/rfc2119):

"SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."

Our File IDs persist until the next reboot. We avoid using fully persistent File IDs to enhance performance.

The concept is that if an application requires a unique ID for a file, it can use an Object ID. However, File IDs offer a sort of intermediate solution, allowing the unique identification of a file while the application is running without incurring the full performance cost associated with requesting and generating an Object ID.