Repository navigation
fix: use filesystem-safe encoding for lock file paths - #1964
Shubham-Padkonde wants to merge 1 commit into
Conversation
|
I compared the CI failures with unchanged upstream On Windows / Python 3.12.6, the utility, update-warning and CLI-help files pass all 19 tests. The two Big5 detection tests fail identically on this branch and upstream (the Big5 subset has 10 passes and 2 failures on each). The other inspected CI failure is the invalid No code or dependency pins were changed for this diagnosis. Would you prefer the parser/charset compatibility work handled separately so this PR stays focused on Unicode lock filenames? Follow-up from a full native Windows comparison with CPython 3.12.10, the version reported by the Windows 3.12 CI job, and matching pip 26.2.1. The PR at |
Some Unicode configuration paths encode to Base64 containing
/.open_with_lockfile()then treats that slash as a directory separator in the temporary lock path and raisesFileNotFoundErrorbefore opening the configuration file.Use URL-safe Base64 so the generated lock name stays a single filename. Add tests for Unicode paths, competing lock acquisition, reopening after release, and cleanup when the context raises, plus a changelog entry.
Validation: 17 utility/update-check tests pass, and changed-file Flake8 passes. The two new Unicode cases fail before the fix. A broader run encountered two Big5 charset-detection failures, both reproduced with unchanged upstream code; the full suite was interrupted during slow network tests, so I cannot claim a complete full-suite pass.