On 9/1/24 12:44 PM, Thiago Macieira via Std-Proposals wrote:
> On Sunday 1 September 2024 09:17:05 GMT-7 Jeremy Rifkin wrote:
>> I agree. Much of the point of standardizing would be providing
>> guarantees about what "same file" means.
>>
>> For wording, one option is to borrow some wording from
>> std::filesystem::equivalent
> And again, as Tom's report showed but he didn't highlight,
> std::filesystem::equivalent will come to different conclusions too.
>
> The MS STL implementation uses GetFileInformationByHandleEx(), so it can
> compare the 128-bit unique identifier. The libstdc++v3 and libcxx
> implementations use GetFileInformationByHandle(), so they suffer from the same
> problem as Coverity did. And then you have Cygwin, whose source of stat() I
> can't find, but is used to supply the builds of GCC, so GCC's fs::equivalent
> will be the Unix implementation through Cygwin, not the native Windows build.

Cygwin depends on newlib <https://sourceware.org/newlib/> for POSIX and
C library support (github mirror
<https://github.com/mirror/newlib-cygwin>). Support for the stat()
family of functions is provided by winsup/cygwin/fhandler/disk_file.cc
<https://github.com/mirror/newlib-cygwin/blob/271292b1fbdc7da7c1ed678836eebe596170e635/winsup/cygwin/fhandler/disk_file.cc>.
Based on path_conv::get_ino_by_handle()
<https://github.com/mirror/newlib-cygwin/blob/271292b1fbdc7da7c1ed678836eebe596170e635/winsup/cygwin/fhandler/disk_file.cc#L188-L199>,
it looks like inodes are retrieved by calling NtQueryInformationFile()
<https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntqueryinformationfile>
with a request to populate a FILE_INTERNAL_INFORMATION
<https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_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()
<https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getfileinformationbyhandleex>
and FILE_ID_INFO
<https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-file_id_info>
would be.

Tom.