Expose Windows VolumeSerialNumber and FileIndex/FileId in std::os::windows::fs::MetadataExt

[Sh4rK]

Currently, using std::os::unix::fs::MetadataExt and std::os::linux::fs::MetadataExt it is possible to get the inode number of a file. This can be useful in determining whether two files are the same. There's a similar concept in Windows, consisting of a few parts:

VolumeSerialNumber: The serial number of the volume that contains the file.
FileIndex: A 64 bit unique (within a volume) identifier that is associated with a file.
FileId: A 128 bit unique (within a volume) identifier that is associated with a file (this is the "evolution" of the above, according to the docs currently only used by ReFS).

Sources: _BY_HANDLE_FILE_INFORMATION _FILE_ID_INFO

Combining the VolumeSerialNumber and FileIndex/FileId of a file is thus a unique identifier of a file on a single machine (at a given time; unique IDs may be reused).

I would like these to get added to std::os::windows::fs::MetadataExt. The changes needed would be fairly tiny (literally just exposing already available data in case of VolumeSerialNumber and FileIndex here but an additional function call for FileId), and it wouldn't introduce any breaking changes as far as I can see, it would only add 2/3 methods. Would this require an RFC?

I see that the RFCs README lists "Additions to std." as an as example, but on the other hand I wouldn't say this is a "substantial" change.

[retep998]

You can already achieve this functionality using same-file. Is there any reason why a third party crate would be inadequate and for you to require this in std directly?

[Sh4rK]

@retep998 You're right. However, I'm also thinking about cases where I don't want to directly compare two handles, but save the unique ID of a file (maybe to disk), and then use it later to check, for example, that a file at a path is the same as before, or different.

The idea comes from https://apenwarr.ca/log/20181113 where he uses a combination of file attributes to detect that a file has likely changed (mtime, size, inode number, file mode, owner uid, gid).

Of course, this can be done using winapi, or even winapi-util, which same-file uses. Also, I don't have any code right now which would use these APIs, I just looked into how it could be done.

The reason I thought it might be a good idea to add it to std is (regardless of what one might use them for):

• The equivalent functionality for Unix and Linux is supported, so it seems odd to leave it out for Windows.
• The code to query the data is already there, we just don't make some fields available, which seems a bit arbitrary. Why does exposing attributes, creation_time, last_access_time, last_write_time and file_size belong in std, but volume_serial_number and file_index (and following this thought, number_of_links) doesn't?

[kadiwa4]

Tracked here: #63010