Repository navigation
fix(desktop): stage native deps via per-file copies to survive non-ASCII Windows paths - #103458
Closed
Tulovecare wants to merge 1 commit into
Closed
Tulovecare wants to merge 1 commit into
Tulovecare wants to merge 1 commit into
Conversation
…CII Windows paths
fs.cpSync({ recursive: true }) crashes the Node process on Windows
(STATUS_STACK_BUFFER_OVERRUN, 0xC0000409, no output) when a path
contains non-ASCII characters, e.g. a user profile like C:\Users\涂.
The desktop pack stages node-pty and get-windows native payloads under
apps/desktop/dist, whose path inherits the user-profile component, so
Windows users with non-ASCII usernames could never complete a local
desktop build - the pack died silently mid-stage.
Replace the two recursive cpSync call sites (whole build/Release dirs
and a conpty/ prebuild subdir) with a copyDirSyncSafe helper that walks
the tree with per-file copies, sidestepping the buggy path. Semantics
are equivalent for these whole-directory copies and file modes are
unchanged (files are still copied with cpSync).
Reference: nodejs/node#60447 (the crash). Regression covered by a
staging test whose fixture path is deliberately non-ASCII and which
asserts nested directories are copied through recursively.
Verified by packaging the desktop app on a Windows host whose user
profile contains CJK characters: previously crashed mid-stage, now
packs cleanly end-to-end.
Duplicate of #60480 - same fix (replace recursive |
Author
teknium1
added a commit
that referenced
this pull request
Sep 17, 2026
…k .bak wipe The salvaged commits drop the cpSync/rmSync imports, but stageGetWindowsInto landed on main after the PR was opened and still called both, so the module threw ReferenceError on every platform (7 vitest failures on the cherry-picked head). Route its six sites through copyFileSync/removeDirSync so get-windows staging survives the same non-ASCII profile paths as node-pty. preserveRollbackBackup had the same rmSync no-op as cleanStaleAppOutDir: a surviving .bak makes renameSync fail, so the previous working build gets wiped instead of kept as rollback material. Same existsSync -> removeDirSync fallback. Earlier fixes for the same crash: #60480 (@liuhao1024), #61832 (@danilofalcao), #76211, #103458, #109273, #111590. Co-authored-by: liuhao1024 <liuhao1024@users.noreply.github.com> Co-authored-by: danilofalcao <danilofalcao@users.noreply.github.com>
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.
PR: fix(desktop): stage native deps via per-file copies to survive non-ASCII Windows paths
Summary
fs.cpSync({ recursive: true })crashes the Node process on Windows(
STATUS_STACK_BUFFER_OVERRUN, 0xC0000409, no output) when a path containsnon-ASCII characters. The desktop pack stages node-pty / get-windows native
payloads under
apps/desktop/dist, which inherits the user-profile pathcomponent — so Windows users whose username is non-ASCII (e.g.
C:\Users\涂)can never complete a local desktop build; the pack dies silently mid-stage
(
npm run packfails with no error,Hermes.exenever gets produced).This replaces the two recursive
fs.cpSynccall sites inapps/desktop/scripts/stage-native-deps.mjs— wholebuild/Releasedirs and aconpty/prebuild subdir — with acopyDirSyncSafehelper that walks the treeusing per-file copies, sidestepping the buggy path. Semantics are equivalent for
these whole-directory copies; file modes are unchanged (files are still copied
with
cpSync).Reference: nodejs/node#60447 (the
underlying Node crash).
Changes
apps/desktop/scripts/stage-native-deps.mjscopyDirSyncSafe(srcDir, destDir)(recursive copy via per-filecpSync)copyBuildRelease(): nested dirs →copyDirSyncSafestageNodePtyInto():conpty/prebuild subdir →copyDirSyncSafeapps/desktop/scripts/stage-native-deps.test.mjsstaging survives non-ASCII source paths (recursive-copy crash workaround): fixture paths deliberately contain CJKcharacters; asserts host
build/Release, a nestedbuild/Release/subdirectory (
.node+ plain file), and a nestedconpty/x64/prebuild dir areall staged. Pre-fix on Windows the recursive
cpSynchard-crashes the testprocess; post-fix it passes everywhere.
Test plan
cd apps/desktop && npx vitest run scripts/stage-native-deps.test.mjsdarwin staging ships the Swift helper executable…asserts POSIX0o755on a helper and fails on a Windows host regardless of this change(Windows does not map exec bits) — pre-existing, unrelated.
Windows 11 host whose user profile contains CJK characters. Before this fix
the pack crashed silently at
stage-native-deps; after, it stagesnode-pty (win32-x64)andget-windows (win32)and packs cleanly.windows-latestthe new test passeswith the fix (and would have hard-crashed pre-fix thanks to its non-ASCII
fixture paths).
Notes
swaps the copy mechanism at existing call sites.
the Node versions Hermes supports, this workaround keeps local desktop builds
working for affected users. Happy to drop it once the engine floor includes a
fixed Node.