[Bug libstdc++/97813] std::filesystem::equivalent returning incorrect results on MinGW due to symlinks

[lennoxhoe at gmail dot com via Gcc-bugs]

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

Lennox Ho  changed:

   What|Removed |Added

 CC||lennoxhoe at gmail dot com

--- Comment #2 from Lennox Ho  ---
> We don't currently support symlinks on Windows.
> There's a lot more than just equivalent that needs to change to support them.

Hi Jonathan, can you elaborate on this?
Is this a simple matter of nobody has bothered to implement this, or are there
blocking issues?

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

[lennoxhoe at gmail dot com via Gcc-bugs]

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 via Gcc-bugs]

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

--- Comment #1 from Lennox Ho  ---
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 via Gcc-bugs]

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

--- Comment #2 from Lennox Ho  ---
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++/97813] std::filesystem::equivalent returning incorrect results on MinGW due to symlinks

[lennoxhoe at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Lennox Ho  ---
Thanks for the insight.

I think the only potential blocker would be CreateSymbolicLinkW requires at
least Vista/WinSer2008.
I'm not able to figure out MinGW (or at least mingw-w64)'s OS requirements.

I might look into contributing a patch to enable Windows symlink support
sometime in the future.

In the meantime, I have a patch for std::filesytem::hard_link_count for
Windows.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663

Thanks

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

[lennoxhoe at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Lennox Ho  ---
Oh right, thanks for pointing that out.
Let me try to put something together.