[Bug libstdc++/113663] New: [MinGW] std::filesystem::hard_link_count always returns 1

[Bug libstdc++/113663] New: [MinGW] std::filesystem::hard_link_count always returns 1

[lennoxhoe at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663

            Bug ID: 113663
           Summary: [MinGW] std::filesystem::hard_link_count always
                    returns 1
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lennoxhoe at gmail dot com
  Target Milestone: ---

Hello!

std::filesystem::hard_link_count() appears to always return 1 when built with
gcc-13.2.0 + mingw-w64ucrt-11.0.1-r3 on Windows 10 19045

Stepping through with a debugger, it looks like hard_link_count() queries
Windows'  _wstat64() for this information.

The MSFT documentation claims this is the expected behaviour for non-NTFS
volumes
https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2013/14h5k7ff(v=vs.120)

However, in my tests both the links are located on the same NTFS volume.
Furthermore, GetFileInformationByHandle does return the correct result of 2.

There appears to be some precedence in calling GetFileInformationByHandle as
seen in std::filesystem::equivalent.
Can hard_link_count() receive the same treatment?

Thanks

[Bug libstdc++/113663] [MinGW] std::filesystem::hard_link_count always returns 1

[lennoxhoe at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663

--- Comment #1 from Lennox Ho <lennoxhoe at gmail dot com> ---
Created attachment 57256
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57256&action=edit
repro.cpp

Added minimal repro

[Bug libstdc++/113663] [MinGW] std::filesystem::hard_link_count always returns 1

[lennoxhoe at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663

--- Comment #2 from Lennox Ho <lennoxhoe at gmail dot com> ---
Created attachment 57257
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57257&action=edit
hard_link_count patch for Windows

I've put together a patch (attached).

[Bug libstdc++/113663] [MinGW] std::filesystem::hard_link_count always returns 1

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #3 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Lennox Ho from comment #2)
> Created attachment 57257 [details]
> hard_link_count patch for Windows
> 
> I've put together a patch (attached).

https://gcc.gnu.org/contribute.html

Patches in Bugzilla won't get a serious review.

[Bug libstdc++/113663] [MinGW] std::filesystem::hard_link_count always returns 1

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-01-30
     Ever confirmed|0                           |1

[Bug libstdc++/113663] [MinGW] std::filesystem::hard_link_count always returns 1

[lennoxhoe at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663

--- Comment #4 from Lennox Ho <lennoxhoe at gmail dot com> ---
Oh right, thanks for pointing that out.
Let me try to put something together.

[Bug libstdc++/113663] [MinGW] std::filesystem::hard_link_count always returns 1

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch
                URL|                            |https://gcc.gnu.org/piperma
                   |                            |il/gcc-patches/2024-January
                   |                            |/644473.html

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I've only just noticed you submitted a patch for this:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644473.html

Libstdc++ patches need to be CC'd to the libstdc++ list, or they won't be seen
by the right people. I've found it now though, so I'll review it ASAP, thanks.