> We know for sure that comparing file paths alone would do the trick

I may have missed something, but, I don’t think we can just dismiss
symbolic links / hard links. That would also be a diversion from existing
practice, at least for GCC/Clang.

Jeremy


On Sun, Sep 1, 2024 at 22:24 Tiago Freire via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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]> 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
>>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>