https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663
--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jonathan Wakely <r...@gcc.gnu.org>: https://gcc.gnu.org/g:658193658f05e9a8ebf0bce8bab15555f43bfee1 commit r15-2408-g658193658f05e9a8ebf0bce8bab15555f43bfee1 Author: Lennox Shou Hao Ho <lennox...@gmail.com> Date: Mon Jul 29 21:09:27 2024 +0100 libstdc++: Fix fs::hard_link_count behaviour on MinGW [PR113663] std::filesystem::hard_link_count() always returns 1 on mingw-w64ucrt-11.0.1-r3 on Windows 10 19045 hard_link_count() queries _wstat64() on MinGW-w64 The MSFT documentation claims _wstat64() will always return 1 *non*-NTFS volumes https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2013/14h5k7ff(v=vs.120) My tests suggest that is not always true - hard_link_count()/_wstat64() still returns 1 on NTFS. GetFileInformationByHandle does return the correct result of 2. Please see the PR for a minimal repro. This patch changes the Windows implementation to always call GetFileInformationByHandle. PR libstdc++/113663 libstdc++-v3/ChangeLog: * src/c++17/fs_ops.cc (fs::equivalent): Moved helper class auto_handle to anonymous namespace as auto_win_file_handle. (fs::hard_link_count): Changed Windows implementation to use information provided by GetFileInformationByHandle which is more reliable. * testsuite/27_io/filesystem/operations/hard_link_count.cc: New test. Signed-off-by: "Lennox" Shou Hao Ho <lennox...@gmail.com> Reviewed-by: Jonathan Wakely <jwak...@redhat.com>
