Skip to content

fix: use filesystem-safe encoding for lock file paths - #1964

Open
Shubham-Padkonde wants to merge 1 commit into
httpie:masterfrom
Shubham-Padkonde:fix/unicode-lockfile-paths
Open

Shubham-Padkonde wants to merge 1 commit into
httpie:masterfrom
Shubham-Padkonde:fix/unicode-lockfile-paths

Conversation

@Shubham-Padkonde

Copy link
Copy Markdown

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 raises FileNotFoundError before 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.

@Shubham-Padkonde

Shubham-Padkonde commented Nov 3, 2026 •

Copy link
Copy Markdown
Author

I compared the CI failures with unchanged upstream 5b604c3, keeping this PR at dab3a07.

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 --pretty choice message: the test expects quoted choices, while CPython 3.12.14's argparse uses str rather than repr for the choice list. Loading that unchanged standard-library module in a Python 3.12.6 compatibility harness reproduces the same 3 passes / 1 failure on both branches. This is not a full native Python 3.12.14 run or a full CI-matrix pass.

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 dab3a07 had 1005 passed, 3 failed, 19 skipped, 4 xfailed. Upstream 5b604c3 had 1002 passed, 3 failed, 19 skipped, 4 xfailed. Both failed the same 3 cases, including the invalid --pretty choice and both Big5 checks. All three lock-file regressions passed on the PR. Running those same three tests against upstream produced two failures and one pass.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant