Don't define what system calls are needed in the standard.
This was always going to be platform dependent.

We know for sure that comparing file paths alone would do the trick. Which doesn't even require opening files, the only thing it requires is to exist to register a hit for your #include directive.
If you need more than that to tell 2 files apart then you can't even guarantee what the "#include" directive is doing.

Is anyone going to argue that "#include" directives are unimplementable?


________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Gašper Ažman via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, September 2, 2024 12:26:03 AM
To: Std-Proposals <std-proposals_at_[hidden]>
Cc: Gašper Ažman <gasper.azman_at_[hidden]>; Tom Honermann <tom_at_[hidden]>
Subject: Re: [std-proposals] Revising #pragma once

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