On Thu, 25 Jun 2026 at 18:47, Jonathan Wakely <[email protected]> wrote: > > 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.
Actually that commit is just a follow-up to this one, which seems to be the main fix: https://github.com/mingw-w64/mingw-w64/commit/fc934554263ce9de070f7691129e7f1fbf15ca4a "crt: Fix fstat() to signal overflow and return correct type for directories"
