+1 to this.

Networked "filesystems" have absolutely no reason to keep inodes stable
between a close and subsequent open. It's a separate curl call.
Is_same_file is actually implementable. That capability hasn't been even
part of Unix file semantics (where open and delete a file before anything
can read it is a thing for security), and those are some of the strictest
around.

The c++ standard has barely any concept of what a source file is; requiring
novel queries of filesystems is a huge leap.

On Sun, Sep 1, 2024, 23:21 Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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).
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>