Repository navigation
Fix long-path extraction past MAX_PATH on Windows (#1468) - #1516
Closed
rockysscenery wants to merge 2 commits into
Closed
rockysscenery wants to merge 2 commits into
rockysscenery wants to merge 2 commits into
Conversation
nup's extractor wrote deep paths raw. makedirs passed but the open of the .part died with ENOENT for any path over 260 characters, so a game folder named normally plus the deepest romfs leaf stopped the build halfway through extraction — right where the reporter hit it. Hand absolute normalized Windows paths to the wide API via the long-path prefix at exactly one choke point (win_long) so no policy about unsafe names or existing links changes. A test fixture authors a deep path that forces the boundary on a machine with long paths enabled and confirms both files land; short-name paths must pass unchanged too. Co-Authored-By: Claude Code <noreply@anthropic.com>
The fixture authors a deep path that forces the boundary on any machine, including ones where Python resolves long raw paths. Two files must land — one >260 characters after joining with the temp root (the failing case in NotRexed#1468), and one short leaf to prove ordinary names pass through win_long unchanged too. Co-Authored-By: Claude Code <noreply@anthropic.com>
Owner
|
Thanks for this. Long paths are handled on main now by #1497, which covers the extraction (as this PR does) and also the game's own file reads, links and the shader census. I played from a game folder whose deepest file path is 374 characters: it reached gameplay with no file errors. Closing this one as superseded. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds one narrow case to
nx2/nup.py: when extracting, hand absolute normalized Windows paths through the long-path prefix (\?\) so deep folders that run past 260 characters work correctly. The whole path logic stays exactly as-is; nothing changes about safety checks or links — just the way Python passes them down to the OS at one choke point (the newwin_longhelper).Why
Right where reporter hit it: extraction died halfway through a game folder named normally plus the deepest romfs leaf. makedirs succeeded but opening
.partgave ENOENT for any path >260 chars because Python uses ANSI APIs without long-path support by default on Windows. This fixes exactly that without touching policy or making unsafe names suddenly legal.Results
Testing performed
nx2/test_nup_paths.pythat specifically breaks without the fix but passes with it (author fixture root + deep leaf >260 total length). Test confirms both short and long names extract correctly regardless of whether your machine has OS-level long path support turned on or off.test_nup_codec,test_nup_verify) — all green, same five pre-existing symlink failures due to lack of Developer Mode privileges on the test machine (unrelated to this change).Closes: #1468
🤖 Generated with Claude Code