diff options
| author | Lennox Shou Hao Ho <lennoxhoe@gmail.com> | 2024-07-29 21:09:27 +0100 |
|---|---|---|
| committer | Jonathan Wakely <redi@gcc.gnu.org> | 2024-07-30 12:55:10 +0100 |
| commit | 658193658f05e9a8ebf0bce8bab15555f43bfee1 (patch) | |
| tree | 02c263cdfe6138da48e6ec350c7a98f4f5246e1c /gcc | |
| parent | 0c382da0943dc7d14455ba2ada2f620a25bd1366 (diff) | |
| download | gcc-658193658f05e9a8ebf0bce8bab15555f43bfee1.zip gcc-658193658f05e9a8ebf0bce8bab15555f43bfee1.tar.gz gcc-658193658f05e9a8ebf0bce8bab15555f43bfee1.tar.bz2 | |
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 <lennoxhoe@gmail.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Diffstat (limited to 'gcc')
0 files changed, 0 insertions, 0 deletions