On Thu, 25 Jun 2026 at 17:52, Jonathan Wakely <[email protected]> wrote: > > On Wed, 24 Jun 2026 at 23:54, Adam Wood <[email protected]> wrote: > > > > > > > > On Wed, Jun 24, 2026 at 2:38 PM Jonathan Wakely <[email protected]> wrote: > >> > >> On Wed, 4 Mar 2026 at 23:17, Adam Wood <[email protected]> wrote: > >> > > >> > > >> > > >> > On Wed, Mar 4, 2026 at 9:14 AM Jonathan Wakely <[email protected]> > >> > wrote: > >> >> > >> >> On Mon, 16 Feb 2026 at 22:42, Adam Wood <[email protected]> > >> >> wrote: > >> >> > > >> >> > Tested on x86_64-w64-mingw32 on Windows 11. > >> >> > > >> >> > The changes in v4 make sure the new symlink functions are only > >> >> > defined/enabled > >> >> > on versions of Windows with symlink support. > >> >> > > >> >> > Because path resolution may be different between Windows and POSIX > >> >> > when a > >> >> > dotdot follows a symlink, I also made some edits to tests involving > >> >> > that > >> >> > specific case. I removed my changes to fs::absolute and > >> >> > fs::canonical because I was misplaced and was trying to force Windows > >> >> > to > >> >> > act like POSIX in that specific case. > >> >> > > >> >> > Finally, I dealt with the issue that creating symlinks with the > >> >> > unprivileged > >> >> > flag returns an error in earlier versions of Windows by just trying > >> >> > again > >> >> > if ERROR_INVALID_PARAMETER occurs without the unpriviledged flag. This > >> >> > is how MSVC STL does it as well. > >> >> > > >> >> > The patch does not support junctions or mount points. > >> >> > >> >> Hi Adam, > >> >> > >> >> Thanks for the new patch. I'm still reviewing it, but I see these > >> >> tests failing using a mingw-w64 cross compiler and testing under Wine: > >> >> > >> >> /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/27_io/filesystem/operations/copy_symlink/1.cc:27: > >> >> void test_successful_copy(const std::filesystem::__cxx11::path&, bool > >> >> (*)(const std::filesystem::__cxx11::path&)): Assertion > >> >> 'is_some_file_type(p2)' failed. > >> >> FAIL: > >> >> /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/27_io/filesystem/operations/copy_symlink/1.cc > >> >> > >> >> > >> >> /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/27_io/filesystem/operations/symlink_status.cc:36: > >> >> void test01(): Assertion 'st1.type() == fs::file_type::directory' > >> >> failed. > >> >> FAIL: > >> >> /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/27_io/filesystem/operations/symlink_status.cc > >> >> > >> >> Do these PASS for you on real Windows? > >> >> > >> > Those tests all PASS on my Windows 11 VM. > >> > >> I've installed a Windows 11 VM. I built all the filesystem tests using > >> a mingw-w64 cross compiler and ran the tests under Wine. For each test > >> that PASSed before your changes and FAILed with your patch, I copied > >> the .exe to the Windows VM and ran it there, and they also FAILed on > >> the VM. So this doesn't seem to be a problem with Wine, the tests FAIL > >> for Windows 11 too. > > > > > > I've been compiling the tests entirely within the Windows VM and msys2 > > terminal. I'll try this method and see if I can fix this. > > I've debugged it a bit and the problem is that > symlink_status(".").type() is returning file_type::regular not > file_type::directory. > > After the call to _fstat64 the stat buffer has st_mode = 33206, so > S_ISREG(st_mode) is true. > > I don't think _ops_osfhandle works for directories, I think it can > only handle regular files, pipes, and character devices. So I think > your __stat_windows function needs to check for a directory before it > opens the file descriptor to pass to _fstat64.
This mingw-w64 commit looks highly relevant: https://github.com/mingw-w64/mingw-w64/commit/100187e25744226a1edd34ecd82e981af7e35411 crt: Fix _wstat() for crtdll.dll/msvcrt10.dll when called on directory CRT _fstat function returns S_IFREG for directories, but CRT _stat function returns S_IFDIR for directories. mingw-w64 fstat functions fixes this _fstat issues, so use fstat for _wstat emulation used for crtdll.dll and msvcrt10.dll builds. This change fixes the t_stat_slash test when compiled against crtdll.dll. This is exactly the problem I'm seeing (using mingw32-headers v13.0.0, which is from before that commit). _fstat is returning S_IFREG for directories.
