filelock is a platform-independent file locking library for Python. It provides a way for Python programs to coordinate access to files and avoid conflicts when multiple processes need the same file.
Project status
- Actively maintained, with an upstream push and an update on November 4, 2026.
- Updates have been very frequent recently, with multiple versions published in late October and early November.
AI summary generated
Recent updates
4.2.9
Version 4.2.9 fixes validation of the `blocking` argument for read-write locks and their async wrappers. Non-boolean values now raise `TypeError` at construction or acquisition instead of being interpreted as truthy or falsey values.
Breaking4.2.8
Release 4.2.8 documents the platform-specific locking behavior of descriptor locks and corrects guidance about compatibility with conda's byte-range locking protocol. The visible package changes are documentation-only, with no public API signature or runtime behavior changes; the diff also includes unmentioned CI, release-process, and development-tooling changes.
4.2.7
Release 4.2.7 fixes SoftFileLease recovery when a dead holder published a different lease duration from its current contenders. A live holder with a different duration still causes LeaseSettingsMismatch.
4.2.6
Release 4.2.6 fixes a race during stale-marker reclamation by rechecking the lock marker before exchanging names and unwinding competing exchanges safely. The code changes support that fix in both takeover cleanup and stale-lock swapping, with no public lock API signature changes apparent in the diff.
4.2.5
Version 4.2.5 is primarily a bug-fix release for lock acquisition, recovery, fork behavior, and read/write locks, with documentation and release-pipeline updates. It also makes `blocking` validation stricter: calls that pass a non-boolean value now raise `TypeError` instead of treating truthy values as `True`.
Breaking4.2.4
Release 4.2.4 makes a small change to how GitHub release notes are formatted and written during the release workflow. The documented note focuses on removing extra blank lines while keeping the PyPI link and version comparison link intact.
4.2.3
Release 4.2.3 primarily fixes two edge cases in FileLock's soft reader/writer locking behavior and interpreter shutdown handling. It addresses an AttributeError during exit for Python 3.15 runtimes where `types.LazyImportType` is absent, and corrects handling of `EFTYPE` when `O_NOFOLLOW` refuses a symlink during soft lock protocol operations.
4.2.2
Release 4.2.2 fixes a bug in the file lock acquire path where the internal hold counter could remain incremented after an acquisition attempt failed because the working directory could not be resolved. The change ensures that the hold count is not bumped if canonicalization of the lock path fails. Associated tests and changelog entries were updated to cover the scenario.
4.2.1
Release 4.2.1 focuses on correctness fixes across synchronous, async, and soft lock implementations, with special attention to cancellation, stale lock reclamation, and path identity behavior (including GraalPy/CI test execution changes). The release notes primarily describe test/CI improvements and targeted bug fixes, but the code diff also shows a few internal API/protocol changes and type-level adjustments that are not called out.
4.2.0
Release 4.2.0 includes a strict locking fix on Windows to skip claims that are pending deletion, and a performance improvement to reduce initial import overhead by deferring loading of asyncio and sqlite3. The code diff shows a broader lazy-import implementation across the package, plus additional Windows probing logic tied to the strict fix.
Features4.1.2
Release 4.1.2 focuses on reliability fixes for read-write locking behavior on older SQLite versions, and improved correctness around async read-write locks during fork/exit scenarios. It also includes documentation and security process updates related to lock filename generation and vulnerability reporting.
BreakingSecurity4.1.1
filelock 4.1.1 focuses on platform robustness (macOS descriptor path handling), hardened ownership parsing (reject hostile PID/start-time data), and improving CI/test determinism. It also updates development and automation to use Python 3.15 by default.
Breaking4.1.0
filelock 4.1.0 includes extensive bug fixes across API validation, marker and lease handling, and async read-write locking. It also adds a small feature to export additional lease-related types and the has_fcntl flag. Most changes are described as fixes in the release notes, but a couple of user-visible behaviors around warnings and exception text were not called out.
Features4.0.12
Release 4.0.12 is a focused fix for acquiring SQLite read locks on older SQLite versions. It changes the internal schema probe query used during lock configuration to improve compatibility.
4.0.11
Release 4.0.11 makes a change to the ReadWriteLock implementation aimed at NetBSD systems where /dev/fd does not expose higher-numbered descriptors, which can prevent SQLite from opening the lock database path correctly. Release notes also include a small contributing guide documentation tweak.
4.0.10
Release 4.0.10 includes a singleton consistency fix so that singleton async locks and soft leases are not reused when their runtime options differ. It also contains a util refactor around test helpers. The core behavior change is enforced in the singleton selection logic (metaclass), and related tests were expanded.
Breaking4.0.9
Version 4.0.9 includes a fix for ReadWriteLock and AsyncReadWriteLock where the file descriptor used to validate the SQLite database path is now closed immediately after connecting, preventing descriptor leaks on runtimes with delayed garbage collection. The release notes also mention a docs update related to util guarantees, but they do not fully capture all behavioral security changes in the underlying ReadWriteLock implementation.
4.0.8
This release fixes a concurrency bug where releasing a write lock from the wrong thread could improperly drop the lock and allow another writer in. The code now enforces write-lock ownership by thread identity, raising RuntimeError when a non-owner thread attempts to release (unless an explicit override is used).
Breaking4.0.7
Release 4.0.7 tightens validation of the lockfile permission mode. If the provided `mode` does not grant the owner read and write, filelock now fails instead of allowing a later, broken state.
Breaking4.0.6
Release 4.0.6 adds stricter validation around acquisition timeouts for read/write locks. When blocking is enabled, negative timeout values (except -1) are now rejected before acquisition, and new tests were added to cover both reentrant and non-reentrant scenarios.
Breaking