[Gruzzberry]

What

On Windows, chflags succeeded on a symbolic link whose target is missing and failed dangling/ with ENOTDIR. FreeBSD 11.4's kern_chflagsat looks the path up with FOLLOW, so both fail with ENOENT.

The cause is the lookup in LookupError: under MinGW, std::filesystem::status does not follow a Windows symbolic link and reports a dangling link as an existing regular file. When the last component (or the one before a trailing slash) is a reparse point, the lookup now goes through the target with File::TryFillFileStat, the guest stat, which already follows links: a missing target gives ENOENT, a link to a file followed by a slash gives ENOTDIR, a link to a directory is accepted. Linux is unchanged; chflags is the only caller of LookupError.

Measured on main with a standalone probe, the same dangling link: stat, truncate, utimes and open already fail with ENOENT; chflags returned 0.

Tested

Windows 11 (10.0.26200), WinLibs MinGW-w64 GCC 15.2.0 r7, Ninja, Release, -DBUILD_TESTING=ON, on main 938812d (rebased; since #9109, chflags("dangling/") fails with ENOTDIR from the trailing-slash check before this lookup runs, so that check was dropped from the test; FreeBSD gives ENOENT there), Developer Mode on so links can be created.

• guest_filesystem: new checks on a dangling link (ENOENT) and a link to a file (0, ENOTDIR with a trailing slash, EOPNOTSUPP for an unknown flag), then both links are removed with unlink. On main the test fails at the first new check (chflags on the dangling link returns 0); with this PR it passes. Without link permission the link checks are skipped with a message.
• guest_kernel_sys: passes.
• Full suite on main 938812d and on main with feat(libkernel_sys): implement lchflags #9442, fix(libkernel): fail chflags through a dangling Windows symbolic link with ENOENT #9469, fix(libc): follow a Windows symbolic link in access #9474, fix(libkernel): follow a Windows symbolic link in chmod #9487, fix(libkernel): fail open with O_CREAT and O_EXCL on a Windows symbolic link #9496, fix(libc): rename onto or from a Windows directory symbolic link like a link #9661 and feat(libkernel_sys): implement settimeofday #9682 merged together, same machine: 2029 tests each; on both, the 3 agc_driver_sample_order* tests fail and agc_driver_image_array_window_past_layer_limit is not built (its 64 KiB alignas is rejected by this MinGW toolchain). In the parallel run (ctest -j 12) one other test failed on the merged branch (guest_memory in one run, guest_kqueue in another, agc_driver_shutdown_threads_queued_prebuilds in both); each passes alone, three runs out of three.
• python tools/check_conventions.py --base upstream/main: passes.
• Not tested: Linux (the change is Windows only; the new checks use std::filesystem::create_symlink there), a console, a title run.

#9442 (lchflags) is independent of this PR; its dangling-link check passes with or without it.

Overlaps

• tools/pr_overlap.py --branch on the rebased head lists no direct overlap; of the 12 pull requests it could not compare, none changes LookupError or chflags. fix(kernel): safely copy guest path arguments #9423 edits the start of chflags_nid_postfix, not LookupError.
• test: organize library tests and label CTest suites #6044 moves GuestFilesystem.cpp to tests/files/; if it lands first, the new cases move with the file in the rebase.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); no silent stubs added
• No notes, investigation .md files or images added to the repository
• New third-party code is a submodule built from source: none added
• Generic behaviour, not specific to one title
• Depends on: none
• Fixes: none
• Unblocks: none
• GPUs tested: n/a
• AI-assisted: yes

AI-assisted (Claude Code).

🤖 Generated with Claude Code

[MarcZX10]

Reviewed the Windows-only lookup path and focused symlink tests. For reparse-point inputs the change follows the target through the existing guest stat helper, preserving ENOENT for a dangling target and checking directory type for trailing separators; the non-reparse path is unchanged. The debt note and limitations are explicit. Conventions, intake, eligibility, labels, and report pass; hosted Windows/Linux build and test jobs were skipped. The Windows 11 focused runs described in the PR are author-reported; I did not run them locally.

[Gruzzberry]

Full suite with this PR merged together with #9442, #9469, #9474 and #9487, against main on the same Windows 11 machine (MinGW-w64 GCC 15.2.0 r7, Release): 1875 tests, the same results except agc_import_settle_first_use, which also skips on main when its copies finish before the import returns (5 of 5 runs).

[github-actions]

Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.

Pull request	Shared files not compared
PR 5021	core/libs/prx/libkernel/File/src/Stdio.cpp
PR 6936	core/libs/prx/libkernel/File/src/Stdio.cpp
PR 7121	core/libs/prx/libkernel/File/src/Stdio.cpp
PR 7201	core/libs/prx/libkernel/File/src/Stdio.cpp
PR 7447	core/libs/prx/libkernel/File/src/Stdio.cpp
PR 8520	core/libs/prx/libkernel/File/src/Stdio.cpp core/libs/tests/GuestFilesystem.cpp
PR 9284	core/libs/prx/libkernel/File/src/Stdio.cpp
PR 9293	core/libs/prx/libkernel/File/src/Stdio.cpp
PR 9297	core/libs/prx/libkernel/File/src/Stdio.cpp
PR 9302	core/libs/prx/libkernel/File/src/Stdio.cpp
PR 9371	core/libs/tests/GuestFilesystem.cpp
PR 9823	core/libs/prx/libkernel/File/src/Stdio.cpp

[MarcZX10]

The Windows-only path and focused symlink cases were reviewed previously, and the reported combined Windows run is useful. The tested commit and the current branch base are still 47 upstream commits behind current main (now 110a18b); the reported baseline is a6dcea9. Please rebase/update onto current main and rerun the focused guest_filesystem checks plus the relevant conventions and overlap checks on that base before treating the earlier results as current. I checked the overlap bot warnings: the listed Stdio.cpp PRs touch other areas, and #6044 does not list GuestFilesystem.cpp, so I found no direct conflict in those warnings. No local test was run for this follow-up.

[Gruzzberry]

Rebased onto main d6eafa5. guest_filesystem and guest_kernel_sys pass on the new head, the new checks fail on that main without the change, and check_conventions.py passes. Full suite on main d6eafa5 and on main with #9442, #9469, #9474, #9487 and #9496 merged together: 1890 tests each, identical results. The overlap scan of the rebased head and a manual check of the pull requests it could not compare are in the description under Overlaps.

[Gruzzberry]

Holding this as a draft, following the direction on #5239: the open queue is above 700 and no named title needs this change on current main. I will only mark it ready again with a current-main title ID, its Game bring-up discussion and the log line where it stops on this, or once the queue is below 700. Thanks for the reviews so far; the requested fixes are being made on the branch in the meantime.

[Gruzzberry]

Rebased onto main 938812d and marked ready for review, as @MarcZX10 noted the #5239 hold does not need to apply here. On Windows (MinGW GCC 15.2.0): the focused tests pass, check_conventions.py passes, and the full suite (2029 tests) on main merged with #9442, #9469, #9474, #9487, #9496, #9661 and #9682 matches main itself, apart from parallel-run flakes that pass when run alone.

Dismissing a stale review: the requested changes were addressed after it (new head) and the merge queue blocks on it. Please request changes again if anything is still open.

[adriadam10]

Checked LookupError against FreeBSD 11.4 kern_chflagsat (FOLLOW lookup) and the new chflags cases (they fail on main); pushed a commit renaming the test locals that clashed in main() and rebased onto current main (scoped build and 358 tests pass). The earlier Linux CI failures (agc_unit_shadow_completion_store, guest_job_manager_worker_spin_scale_10) are unrelated to this Windows-only change; merged.