Fileid vs ObjectID for NTFS

[JC-RFC]

I have been working through a compatibility issue between FFS and Drivepool.

The Drivepool devs are suggesting that FileID may not be the best method for detecting file renames and moves on NTFS.

... incorrectly using File IDs as persistent file identifiers, which they should not be. File IDs in Windows can change from time to time on some filesystems.

Source: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/ns-fileapi-by_handle_file_information

The identifier that is stored in the nFileIndexHigh and nFileIndexLow members is called the file ID. Support for file IDs is file system-specific. File IDs are not guaranteed to be unique over time, because file systems are free to reuse them. In some cases, the file ID for a file can change over time.

If this is the case, then it is expected behavior.

The correct API to use to get a persistent file identifier is FSCTL_CREATE_OR_GET_OBJECT_ID or FSCTL_GET_OBJECT_ID: https://learn.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioctl-fsctl_create_or_get_object_id

Object IDs are persistent and do not change over time.

We support both Object IDs and File IDs.
viewtopic.php?p=41740#p41740

https://community.covecube.com/index.php?/topic/12577-beware-of-drivepool-corruption-file-deletion-performance-degradation-scenarios-windows-1011/


Would the FFS dev be open to changing to ObjectID or are there significant performance (or other) issues in considering this?

I ask because syncing between my Drivepool and backup locations is painful when a large number of large files have been moved or renamed.

Looking further through that MS document myself though it seems to me that with NTFS File-id is persistent for the life of a file.

[Zenju]

Let's see...
File object IDs are supported only on NTFS volumes

But for NTFS we have:
In the NTFS file system, a file keeps the same file ID until it is deleted

Ergo:
Object ID = useless
File ID = perfect as persistent file identifier (on NTFS).

[xCSxXenon]

It sounds like DrivePool devs are really leveraging the "File IDs are not guaranteed to be unique over time, because file systems are free to reuse them" that Microsoft puts in the documentation, instead of maybe getting their software to work how most other software works

[JC-RFC]

Thanks for the reply Zenju,

My take on the MS documents is that FileID is a valid (and the best) mechanism for tracking files on NTFS, and I see why you wouldn’t bother with ObjectID if it doesn’t work with FAT anyway.

I agree that this should be addressed in Drivepool, thanks for your time.