Repository navigation
lib/encoder: fix decoding a trailing character after an escaped quote - #10036
Merged
Merged
Conversation
ncw
approved these changes
Oct 13, 2026
ncw
left a comment
Member
There was a problem hiding this comment.
Thank you for this, and for the clear write-up - looks great :-)
If you'd like to look at the EncodeDot case you mentioned (".." and ".." colliding), a separate PR would be welcome. That one is a genuine encoding collision rather than a decode bug, so it may need a bit of discussion first about what the right encoding should be.
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 does this change do?
MultiEncoder.Decodegets a trailing replaced character wrong when the original name has a literal‛(U+201B,QuoteRune) just before it. Any ofRightSpace,RightPeriodorRightCrLfHtVtis affected:Encodeis correct: it escapes the literal quote as‛‛and replaces the trailing space with␠. On the way back, the suffix code inDecodeonly checks whether the rune before␠/./␉…is aQuoteRune. If it is,Decodetreats the symbol as a quoted literal. That check doesn't account for the quote being the second half of an escaped‛‛. So a file nameda‛on a remote whose encoding includesRightSpace(OneDrive, Windows local, etc.) is decoded asa‛␠.The fix counts the run of
QuoteRunes before the trailing symbol. Only an odd count means the last quote applies to the symbol. The prefix side scans from the start and doesn't have this problem.I found this with a randomized
Decode(Encode(s)) == scheck over random masks and names. With this change, the only round-trip failures left in that check are a separateEncodeDotcase (".."/".."encode to"..", which decodes to".."). I've left that out of this PR so the change stays minimal.Linked issue
None. This is a small, self-contained decoding fix.
Checklist
test_allpasses for this backend and if submitting a new backend can provide a test account for the integration tester - see CONTRIBUTING.md. (n/a)TestEncodeQuoteBeforeRightEdgefails on master for 4 of its 5 cases (the decode errors above) and passes with the fix.go test ./lib/... ./backend/local/...andgolangci-lint run ./lib/encoder/pass.