Comparing changes

_read_marker in the soft read/write lock opens marker files with O_RDONLY | O_NOFOLLOW but no O_NONBLOCK, which is the same gap #548 closed in _soft._read_lock_file. I was going through the soft_rw markers after that change and noticed O_NOFOLLOW only rejects a symlink, not a real FIFO, so a non-cooperating same-UID process can pre-create a named pipe at a predictable marker path like foo.lock.write and any peer that reads it during stale-break or slot-claim blocks forever on the open, all while holding the state SoftFileLock. Adding O_NONBLOCK makes the open return at once so a hostile FIFO reads as a malformed marker and gets evicted like any other stale entry. --------- Co-authored-by: Bernát Gábor <[email protected]>

@dxbjavid

…#551) A process sharing the lock directory on the same host could swap a held soft lock file for a symlink pointing at an old file, so the lifetime check saw the target's stale mtime, a waiter broke the still-live lock, and two processes held it at once. 🔒 This builds on @dxbjavid's #550, which switched the lifetime check to `os.lstat` so it reads the symlink's own mtime, and closes the remaining gaps in the same stale-breaking path. Breaking a stale lock now claims the file by inode before removing it. A shared `break_lock_file` helper renames the lock to a process-private name, re-checks the modification time, and unlinks only when it still matches the value seen at the stale decision. A newer time means a peer recreated the lock in the gap, so the helper leaves the file in place rather than deleting it out from under a live holder. Both the soft lock and the lifetime path use this helper, replacing the duplicated rename logic. Malformed lock files self-heal more reliably too: a non-integer PID or creation time now counts as unparseable, so a two or three line garbage file gets evicted once it ages past the safety window instead of wedging acquirers forever. `AsyncReadWriteLock` gained a destructor that shuts down the single-thread executor it owns, so forgetting to call `close()` no longer leaks the worker thread, while a caller-supplied executor stays untouched. Reviewers should know that releasing a soft lock may now remove the lock file as part of self-healing, and that filelock evicts malformed files automatically after a brief safety window. Supersedes #550. 🙏 --------- Co-authored-by: dxbjavid <[email protected]>

is_lock_held_by_us compares only the pid from the lock file against os.getpid() and ignores the hostname stored alongside it, so on a shared filesystem where the same pid is live on two hosts a lock genuinely held by another node is reported as held by us, and a caller acting on that by releasing or breaking it can drop a lock another host still holds. the lock file already records the hostname for exactly this disambiguation and the stale-break path checks it, so this reads the holder through _parse_lock_holder and requires both the pid and the hostname to match before returning true. added a regression case to the existing is_lock_held_by_us parametrisation covering a same-pid, different-host file.

updates: - [github.com/astral-sh/ruff-pre-commit: v0.15.15 → v0.15.16](astral-sh/ruff-pre-commit@v0.15.15...v0.15.16)  Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

Commits on Jun 10, 2026

Release 3.29.2

gaborbernat committed Jun 10, 2026

Configuration menu

View commit details

Copy full SHA for d9216de

Browse repository at this point

Copy the full SHA

d9216de View commit details

Browse the repository at this point in the history

Navigation Menu

Repository navigation

Comparing changes

Open a pull request

Commits on Jun 4, 2026

Commits on Jun 6, 2026

Commits on Jun 8, 2026

Commits on Jun 9, 2026

Commits on Jun 10, 2026

This comparison is taking too long to generate.

Uh oh!