fix(amuled): force UTF-8 file-name conversion on macOS - #318
Merged
Conversation
On macOS wxLocale::GetSystemEncodingName() returns "Mac OS Roman" regardless of the user's locale, and amuled feeds that into the wxConvBrokenFileNames it installs as wxConvFileName. Mac Roman encodes non-ASCII characters as single high bytes (e.g. U+00AA -> 0xAA), which HFS+/APFS reject as invalid UTF-8 (EILSEQ) when the completed file is opened. The download is then left in PS_ERROR and never moves from Temp to Incoming. macOS file systems are always UTF-8, so force encName to UTF-8 there. This matches the GUI, which never overrides wxConvFileName and so keeps wx's default UTF-8 converter (which is why the GUI was unaffected). Scoped to __WXOSX__: no effect on Linux (block unchanged) or Windows (the whole __UNIX__ block is compiled out there).
got3nks
marked this pull request as ready for review
July 6, 2026 12:36
LSalami
added a commit
to LSalami/amule
that referenced
this pull request
Jul 28, 2026
…literal got3nks's review on amule-org#664: a raw ⌥ literal in a narrow string is converted to wxString via the locale-dependent wxConvLibc, and macOS reports GetSystemEncodingName() as Mac OS Roman (the same narrow-conversion quirk amule-org#318 had to work around under __WXOSX__ elsewhere in the tree). Under a non-UTF-8 conversion those bytes would render as mojibake or collapse to empty instead of the glyph. wxUniChar(0x2325) builds it from the codepoint directly, sidestepping the conversion entirely. po/ regenerated: zero msgid changes, confirming the suffix still never touches a translated string. Verified for real this time, not just build-and-run: launched the app and hovered a toolbar button on macOS -- the tooltip reads "Finestra reti (⌥N)", the glyph renders correctly.
LSalami
added a commit
to LSalami/amule
that referenced
this pull request
Jul 28, 2026
…literal got3nks's review on amule-org#664: a raw ⌥ literal in a narrow string is converted to wxString via the locale-dependent wxConvLibc, and macOS reports GetSystemEncodingName() as Mac OS Roman (the same narrow-conversion quirk amule-org#318 had to work around under __WXOSX__ elsewhere in the tree). Under a non-UTF-8 conversion those bytes would render as mojibake or collapse to empty instead of the glyph. wxUniChar(0x2325) builds it from the codepoint directly, sidestepping the conversion entirely. po/ regenerated: zero msgid changes, confirming the suffix still never touches a translated string. Verified for real this time, not just build-and-run: launched the app and hovered a toolbar button on macOS -- the tooltip reads "Finestra reti (⌥N)", the glyph renders correctly.
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
1 participant
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.
Symptom
On macOS, headless
amuledleaves any finished download whose name contains a non-ASCII character (e.g.ª,ñ,é) stuck inPS_ERROR— it never moves fromTemp/toIncoming/. ASCII-named downloads complete fine, and the monolithic GUI is unaffected. The log shows:"Illegal byte sequence" is
EILSEQfromopen().Root cause
amuledinstalls its ownwxConvFileNameat startup, derived fromwxLocale::GetSystemEncodingName():On macOS that function returns
"WESTERN (MAC OS ROMAN)"regardless of the user's locale (verified underC,C.UTF-8, anden_US.UTF-8). The resulting converter encodesª(U+00AA) as the single byte0xAAinstead of UTF-80xC2 0xAA. Since HFS+/APFS require UTF-8 file names,open()rejects the lone0xAAwithEILSEQ, and completion aborts intoPS_ERROR.The block was written for Linux, where
GetSystemEncodingName()returns the locale charset (normally UTF-8), so it's correct there. It has been wrong on macOS since it was added in 2016, and3.0.1behaves identically — this is a long-standing bug, not a regression.LC_CTYPEis irrelevant (the converter uses an explicit charset name, not the locale).The GUI escapes because it never overrides
wxConvFileName, keeping wx's default macOS UTF-8 converter (which produces the correct0xC2 0xAA).Fix
macOS file systems are always UTF-8, so force
encName = "UTF-8"under__WXOSX__. This makes the daemon match the GUI.Scope / risk
__WXOSX__undefined → block unchanged → no effect.__UNIX__block is already compiled out → no effect.amulecmd/amulewebdon't overridewxConvFileName, so they already use the correct default on macOS.Verification
macOS Debug+Release builds via CI. Local runtime repro (complete a non-ASCII-named download under
amuled, confirm it lands inIncoming/) pending — will update before marking ready.