Comparing changes

) ReadWriteLock.release() rolls back the transaction on the shared sqlite3 connection outside _transaction_lock, even though acquire() runs its own BEGIN under that lock. Once release has put lock_level back to 0 inside the internal lock but has not yet rolled back, another thread acquiring on the same instance sees the level at 0, takes _transaction_lock and issues BEGIN against the connection whose transaction is still open, which raises "cannot start a transaction within a transaction" (re-raised, since it is not a "database is locked" timeout); in the reverse ordering the rollback instead ends the new holder's freshly started transaction and quietly drops the database lock while it still thinks it holds it. The added test parks the rollback with the level already at 0 and shows the racing acquirer now waits rather than erroring. Wrapping the rollback in _transaction_lock keeps it serialised against acquire the same way the rest of the transaction work already is. --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

updates: - [github.com/python-jsonschema/check-jsonschema: 0.37.2 → 0.37.3](python-jsonschema/check-jsonschema@0.37.2...0.37.3) - [github.com/tox-dev/pyproject-fmt: v2.23.0 → v2.24.1](tox-dev/pyproject-fmt@v2.23.0...v2.24.1) - [github.com/astral-sh/ruff-pre-commit: v0.15.16 → v0.15.17](astral-sh/ruff-pre-commit@v0.15.16...v0.15.17) - [github.com/rbubley/mirrors-prettier: v3.8.3 → v3.8.4](rbubley/mirrors-prettier@v3.8.3...v3.8.4)  --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Bernát Gábor <gaborjbernat@gmail.com>

) Co-authored-by: Bernát Gábor <gaborjbernat@gmail.com>

raise_on_not_writable_file is the pre-acquire writability/exists gate used by SoftFileLock and WindowsFileLock, and it still uses os.stat which follows symlinks. If a hostile process plants a symlink at the lock path, the check inspects the link target rather than the lock path itself, so a symlink to a directory raises IsADirectoryError and a symlink to a read-only file raises PermissionError, turning a normal contended acquire into a misleading hard failure and leaking whether arbitrary target paths are writable to the caller. The actual open already uses O_NOFOLLOW and refuses a symlinked lock file, and every other lock-path op here (the O_NOFOLLOW reads, the lstat in break_lock_file and the lifetime check) already declines to follow symlinks, so this precheck was the odd one out. Switching it to os.lstat reads the link itself; behaviour is unchanged for ordinary lock files, and a real read-only file or directory is still rejected.

updates: - [github.com/tox-dev/pyproject-fmt: v2.24.1 → v2.25.0](tox-dev/pyproject-fmt@v2.24.1...v2.25.0) - [github.com/astral-sh/ruff-pre-commit: v0.15.17 → v0.15.18](astral-sh/ruff-pre-commit@v0.15.17...v0.15.18) - [github.com/zizmorcore/zizmor-pre-commit: v1.25.2 → v1.26.1](zizmorcore/zizmor-pre-commit@v1.25.2...v1.26.1)  --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Bernát Gábor <gaborjbernat@gmail.com>

the writer acquire is two-phase, and in phase 2 (waiting for readers to drain) it refreshes the .write marker on every scan. if the writer is paused longer than stale_threshold a peer can evict that now-stale marker and reclaim the slot with its own token, but phase 2 carried on touching whatever sat at the path and reported success once the readers had gone, so the original writer would finish its acquire on top of the peer's live marker and two writers could end up believing they hold the exclusive lock at the same time. this re-checks that the marker still carries our token before refreshing it, the same identity check the heartbeat refresh and the release path already rely on, and re-claims the slot (waiting behind the peer when it currently holds .write) instead of trusting a foreign marker. the regression test drives the eviction mid phase-2 and asserts the acquire no longer completes on a stranger's marker.

updates: - [github.com/tox-dev/pyproject-fmt: v2.25.0 → v2.25.1](tox-dev/pyproject-fmt@v2.25.0...v2.25.1) - [github.com/astral-sh/ruff-pre-commit: v0.15.18 → v0.15.20](astral-sh/ruff-pre-commit@v0.15.18...v0.15.20) - [github.com/rbubley/mirrors-prettier: v3.8.4 → v3.9.1](rbubley/mirrors-prettier@v3.8.4...v3.9.1)  --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

break_lock_file renames a stale lock aside before re-checking and unlinking it, but the aside name is a fixed `<lock>.break.<pid>`. Two breakers in the same process share that name (a thread pool where each worker holds its own lock instance with a lifetime, all contending on one expired lock), so a second break can rename a freshly recreated live lock onto that path in the small window between the re-verify lstat and the unlink, and the first breaker then deletes a live lock the inode check just approved, letting a second holder in. The soft read/write marker break already appends a random token to its aside name for exactly this reason; this makes break_lock_file do the same so no peer can target our break path.

## Problem Since `03b0ab7` (`feat(unix): delete lock file on release`), `UnixFileLock._release()` unlinks the path before unlocking and closing the fd. That lets a process that already opened the old inode keep waiting on that deleted file while another process recreates the filename and locks a new inode, so both can believe they hold the same lock. Fixes #574. ## Solution - stop unlinking the Unix lock file on release - keep the Unix-specific expectations aligned with the persistent-path behavior - add a regression that proves a waiter fd cannot acquire a different inode after another lock instance reacquires the same path ## Testing - `.venv-ci/bin/python -m pytest tests/test_filelock.py tests/test_unix_fallback.py tests/test_self_deadlock.py -q` - `.venv-ci/bin/python -m ruff check src/filelock/_unix.py tests/test_filelock.py tests/test_unix_fallback.py tests/test_self_deadlock.py` - `.venv-ci/bin/python -m ruff format --check src/filelock/_unix.py tests/test_filelock.py tests/test_unix_fallback.py tests/test_self_deadlock.py`

Co-authored-by: Bernát Gábor <gaborjbernat@gmail.com>

…#573)

Navigation Menu

Uh oh!

Uh oh!

Comparing changes

Open a pull request

Commits on Jun 15, 2026

Commits on Jun 16, 2026

Commits on Jun 19, 2026

Commits on Jun 21, 2026

Commits on Jun 24, 2026

Commits on Jun 29, 2026

Commits on Jul 2, 2026

Commits on Jul 3, 2026

This comparison is taking too long to generate.

Uh oh!