Date: Sun, 01 Sep 2024 15:21:05 -0700
On Sunday 1 September 2024 14:12:38 GMT-7 Tom Honermann wrote:
> Cygwin depends on newlib for POSIX and C library support (github mirror).
> Support for the stat() family of functions is provided by
> winsup/cygwin/fhandler/disk_file.cc. Based on
> path_conv::get_ino_by_handle(), it looks like inodes are retrieved by
> calling NtQueryInformationFile() with a request to populate a
> FILE_INTERNAL_INFORMATION structure. The documentation for
> NtQueryInformationFile states:
>
> > A FILE_INTERNAL_INFORMATION structure. This structure specifies a 64-bit
> > file ID that uniquely identifies a file in NTFS. On other file systems,
> > this file ID is not guaranteed to be unique. The documentation for
> > FILE_INTERNAL_INFORMATION states:
>
> File reference numbers, also called file IDs, are guaranteed to be unique
> only within a static file system. They are not guaranteed to be unique over
> time, because file systems are free to reuse them. Nor are they guaranteed
> to remain constant. For example, the FAT file system generates the file
> reference number for a file from the byte offset of the file's directory
> entry record (DIRENT) on the disk. Defragmentation can change this byte
> offset. Thus a FAT file reference number can change over time. I have no
> idea if this is more reliable than using GetFileInformationByHandleEx() and
> FILE_ID_INFO would be.
Given that GetFileInformationByHandle returned a 64-bit number and that was
extended to 128-bit for the Ex version, the most likely scenario is that the
NtQueryInformationFile() returns what GetFileInformationByHandle() returns
(it's likely how the latter is implemented).
Still, the OS does not control what remote filesystems do, especially when you
talk about networked filesystems that have no concept of a unique identifier,
including those that aren't meant to be a networked filesystem in the first
place (I am looking at you, rclone).
> Cygwin depends on newlib for POSIX and C library support (github mirror).
> Support for the stat() family of functions is provided by
> winsup/cygwin/fhandler/disk_file.cc. Based on
> path_conv::get_ino_by_handle(), it looks like inodes are retrieved by
> calling NtQueryInformationFile() with a request to populate a
> FILE_INTERNAL_INFORMATION structure. The documentation for
> NtQueryInformationFile states:
>
> > A FILE_INTERNAL_INFORMATION structure. This structure specifies a 64-bit
> > file ID that uniquely identifies a file in NTFS. On other file systems,
> > this file ID is not guaranteed to be unique. The documentation for
> > FILE_INTERNAL_INFORMATION states:
>
> File reference numbers, also called file IDs, are guaranteed to be unique
> only within a static file system. They are not guaranteed to be unique over
> time, because file systems are free to reuse them. Nor are they guaranteed
> to remain constant. For example, the FAT file system generates the file
> reference number for a file from the byte offset of the file's directory
> entry record (DIRENT) on the disk. Defragmentation can change this byte
> offset. Thus a FAT file reference number can change over time. I have no
> idea if this is more reliable than using GetFileInformationByHandleEx() and
> FILE_ID_INFO would be.
Given that GetFileInformationByHandle returned a 64-bit number and that was
extended to 128-bit for the Ex version, the most likely scenario is that the
NtQueryInformationFile() returns what GetFileInformationByHandle() returns
(it's likely how the latter is implemented).
Still, the OS does not control what remote filesystems do, especially when you
talk about networked filesystems that have no concept of a unique identifier,
including those that aren't meant to be a networked filesystem in the first
place (I am looking at you, rclone).
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering
Received on 2024-09-01 22:21:15