fix(updater): make the Windows swap script survive non-ASCII paths - #870
Merged
marcinz606 merged 1 commit intoAug 17, 2026
Merged
Conversation
cmd.exe parses a batch file in the console OEM codepage, but _spawn_elevated_bat writes it as UTF-8. The staging path under %TEMP% carries the profile name, so for any user whose Windows account name has a non-ASCII character every path line in the swap script garbles: start cannot find the downloaded installer, nothing installs, and explorer cannot restart the app. Self update silently does nothing. Put `chcp 65001 >nul` on the first line after `@echo off`. That line is pure ASCII, so it parses identically under any codepage, and every line after it is read as the UTF-8 the file is actually written in. Verified on Windows 11 (OEM cp437) with a ShellExecuteW-spawned console: a batch referencing an accented path, written UTF-8 the way _spawn_elevated_bat writes it, reports the file missing; with the prologue the same file is found.
activexray
pushed a commit
to activexray/NegPy
that referenced
this pull request
Aug 17, 2026
…arcinz606#870) cmd.exe parses a batch file in the console OEM codepage, but _spawn_elevated_bat writes it as UTF-8. The staging path under %TEMP% carries the profile name, so for any user whose Windows account name has a non-ASCII character every path line in the swap script garbles: start cannot find the downloaded installer, nothing installs, and explorer cannot restart the app. Self update silently does nothing. Put `chcp 65001 >nul` on the first line after `@echo off`. That line is pure ASCII, so it parses identically under any codepage, and every line after it is read as the UTF-8 the file is actually written in. Verified on Windows 11 (OEM cp437) with a ShellExecuteW-spawned console: a batch referencing an accented path, written UTF-8 the way _spawn_elevated_bat writes it, reports the file missing; with the prologue the same file is found.
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
2 participants
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.
On Windows the in-app updater writes its swap script as a UTF-8 .bat, but cmd.exe parses a batch file in the OEM codepage. The installer is staged under %TEMP%, whose path carries the account name, so for a user whose account name has a non-ASCII character every path decodes wrong: start cannot find the installer, nothing installs, and explorer cannot relaunch the app. The update silently does nothing.
Putting chcp 65001 on the first line after @echo off fixes it: pure ASCII, so it parses the same under any codepage, and cmd reads the rest as the UTF-8 the file is written in. The POSIX scripts are untouched.
Verified on Windows 11 (OEM cp437) through a ShellExecuteW-spawned console: an accented staging path resolves the installer only with the prologue present. Every line after the chcp switch still ran, so the old pre-1903 chcp 65001 parsing regression does not bite on the Windows 10 and 11 builds NegPy targets. A full elevated install needs a signed build and admin, so this confirms the path resolution, not the install downstream.