[MarcZX10]

What

When sceKernelOpen fails after path resolution, its existing log shows only the guest path and flags. This made a missing file under /app0 look like a successful lookup in #6006. Log the resolved host path and returned guest error for native-open failures; log the resolution error and returned guest error when path resolution itself fails. The syscall's return behavior is unchanged.

GuestFilesystem now captures the failure log for a missing .pak file and checks the guest path, resolved path and ENOENT result.

Tested

• Linux, GCC 12.2, Release: guest_filesystem_tests builds.
• ctest -R '^guest_filesystem$' cannot reach the test body on this host: startup rejects the Xeon E5-1620 v2 because it lacks LZCNT, BMI1, BMI2, MOVBE, AVX2 and FMA.
• python3 tools/check_conventions.py --base upstream/main passes.
• git diff --check passes.
• Not tested: Windows or a game run.

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; 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)
• Generic behavior, not specific to one title
• Depends on: none
• Unblocks: none
• GPUs tested: n/a
• AI-assisted: yes

[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/Open.cpp
PR 6044	core/libs/tests/GuestFilesystem.cpp
PR 6541	core/libs/tests/GuestFilesystem.cpp
PR 6936	core/libs/prx/libkernel/File/src/Open.cpp
PR 7201	core/libs/prx/libkernel/File/src/Open.cpp
PR 7299	core/libs/prx/libkernel/File/src/Open.cpp
PR 7332	core/libs/prx/libkernel/File/src/Open.cpp
PR 7467	core/libs/tests/GuestFilesystem.cpp

[MarcZX10]

Rebased onto current main (5d9dcc42d) as 59704b5ed. I resolved the Open.cpp conflict by retaining the current module-aware ResolvePathError_nid_no_patch call and layering the PR’s failure diagnostics around it. The diff remains limited to the existing open-failure logging and its regression test. git diff --check and tools/check_conventions.py --base upstream/main pass; the updated hosted checks have not reported yet.

[MarcZX10]

Rebased onto current main a7f108030 as 2b8e37ae0. I resolved the Open.cpp overlap by retaining main’s archived-path resolution (ResolvePathError_nid_no_patch(..., module, true)) and the PR’s path/error logging. The commit remains authored by MarcZX100. git diff --check and tools/check_conventions.py --base upstream/main pass. I could not run the focused build here: the isolated worktree lacks its SDL2 submodule, and CMake stops because SDL has no XRandR support in this environment.

[adriadam10]

Checked the build, guest_filesystem (passes with the change, fails with Open.cpp reverted) and the scoped ctest on Linux; the Windows path of CaptureStderr goes through the full Build before merging. Return values of sceKernelOpen are unchanged; merging.

[MarcZX10]

Thanks for checking the Linux build and the guest_filesystem positive/revert control. I checked the hosted checks on the current head: the Windows Build job is skipped, so that does not validate the Windows CaptureStderr path. I will keep the PR open pending a full Build that actually exercises that path.

[MarcZX10]

I checked whether I could start the workflow’s manual full Build for this PR, but GitHub rejected the dispatch with 403: Must have admin rights to Repository. The automatic Windows job is still skipped. Could a maintainer trigger the configured full Build on this head when convenient? Until it runs, the Windows CaptureStderr path remains unverified.

[MarcZX10]

Clarification after checking the completed workflow eligibility logs: the two concurrent full Build runs are for #6814 and #6892, not #6132. They do not exercise this PR’s Windows CaptureStderr path; its Windows validation remains pending.

[cadenasynyster]

Windows run of the CaptureStderr path, since the Windows Build job was skipped on this head.

Windows 11 10.0.26200.9711, WinLibs GCC 15.2.0 r7 (UCRT), Release, BUILD_TESTING=ON, Developer Mode on. Head 2b8e37a merged onto main b51c65d with no conflicts, no new build errors.

• ctest -R "^guest_filesystem$" -j1: passes 3 of 3 (0.12-0.16 s).
• Control: same tree with only core/libs/prx/libkernel/File/src/Open.cpp restored from main. guest_filesystem fails with Filesystem check failed at line 258 (guest errno 2, Win32 error 2). In the merged file, line 258 is Require(openLog.find("path=" + missing) != std::string::npos);.

So on Windows the _dup/_dup2 redirect into tmpfile() captures the stderr log, the new assertions pass with this change and fail without it, and the open still returns 0x80020002.

Not checked: a title run, and the rest of the suite with this change.

AI-assisted: yes

[MarcZX10]

Thanks for the Windows control run. This confirms CaptureStderr captures the resolved-path diagnostic on WinLibs/UCRT and that the focused guest_filesystem assertions distinguish the PR from main. The Linux result plus this Windows comparison provide useful coverage across both implementations; I have no further review request on this path.

[oneandonlydean]

Merged while @adriadam10 is away: the review passed and full CI is green on this head.