Skip to content

Update filelock requirement from <4.1,>=3.4 to >=3.4,<4.2 - #571

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/pip/filelock-gte-3.4-and-lt-4.2
Open

Update filelock requirement from <4.1,>=3.4 to >=3.4,<4.2#571
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/pip/filelock-gte-3.4-and-lt-4.2

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Oct 18, 2026

Copy link
Copy Markdown
Contributor

Updates the requirements on filelock to permit the latest version.

Release notes

Sourced from filelock's releases.

4.1.0

What's Changed

New Contributors

Full Changelog: tox-dev/filelock@4.0.12...4.1.0

Changelog

Sourced from filelock's changelog.

########### Changelog ###########

.. towncrier-draft-entries:: Unreleased

.. towncrier release notes start

4.2.1 (2026-10-17)

  • On a singleton wrapper, :meth:AsyncReadWriteLock.close() <filelock.AsyncReadWriteLock.close> and :meth:AsyncSoftReadWriteLock.close() <filelock.AsyncSoftReadWriteLock.close> end only the holds that tasks acquired through that wrapper. A reader that arrives during close() gets the closed error instead of joining the ending hold. After synchronous code closes or force-releases the shared lock, the wrappers refuse to admit readers into the ended hold, and close() on such a wrapper returns. Closing one wrapper no longer ends a task's nested hold taken through another wrapper on the same path. :pr:832
  • :class:~filelock.ReadWriteLock locks again after a release() that an exception from a signal handler interrupted. The async read-write wrappers stop admitting readers into such a level. The async read-write locks forget a hold whose backend release failed after the backend let go, and they free the memory of each acquire that times out or is canceled. :class:~filelock.AsyncFileLock returns from release() after a few hundred acquires gave up behind a waiting one. An exception from a signal handler delivered while an :class:~filelock.AsyncFileLock call joins its queue no longer blocks every later call on that lock. :pr:833
  • Fix :class:~filelock.ReadWriteLock acting on -journal, -wal or -shm files another process puts beside its database: a write could land in another file, a reader could get in beside a writer, and an acquire could fail. SQLite now opens the database by name only in a directory no other account can write, and through a private hard link elsewhere. On Windows the directory's access control list decides. Where hard links are unavailable, keep the database in a directory other accounts cannot write, such as one under %LOCALAPPDATA%. The lock removes link directories through a checked descriptor rather than by name, reads a link directory's name only when the locking account owns it, and leaves alone a directory with other content renamed onto a link directory's name. A database whose schema takes more than a few kilobytes to load raises :class:ValueError instead of running past the acquire timeout. :pr:834
  • Fix five bugs in opening the lock file. :class:~filelock.UnixFileLock no longer truncates a file it did not create, such as one renamed to the lock path, and no longer applies mode to it. An on_acquired hook that writes holder metadata now truncates the file itself. A lease (Linux) or an oplock (Windows) on the lock file or a soft lock's marker no longer holds acquire() past its timeout or blocking=False, and an oplock no longer holds release(); :class:~filelock.ReadWriteLock on Windows waits for its timeout and raises :class:~filelock.Timeout. On Windows, a mode without group and other bits, such as 0o600, now creates the lock file with an owner-only permission list; the :class:~filelock.ReadWriteLock database gets the same. The soft locks' writability check no longer follows a symlink swapped in at the lock path. On a filesystem without flock, a contender from another account now waits on a marker it cannot write instead of raising PermissionError. :pr:835
  • Fix :class:~filelock.SoftFileLock, :class:~filelock.MarkerSoftFileLock and :class:~filelock.SoftFileLease removing a live holder's marker in three cases: the holder and the contender run in Linux time namespaces with different boottime offsets; only one of them can read the boot id; a process other than the owner rewrote the marker. Soft markers no longer carry group or other write bits. A process name containing a carriage return or another line separator no longer makes the stale check raise :class:ValueError. When /proc/self/ns/time exists but cannot be read, the stale check no longer compares start times and keeps the marker. :pr:836
  • The async read-write locks record their hold under a task owner, so synchronous code on the executor thread that took the hold can no longer re-enter or release it. :class:~filelock.AsyncSoftReadWriteLock gives back one level on release, so synchronous readers of a shared singleton keep theirs. :class:~filelock.SoftReadWriteLock tracks read levels per thread: release() from a thread that holds none raises :class:RuntimeError. After its heartbeat

... (truncated)

Commits
  • 6c0ecc2 Release 4.1.0
  • df06bbd 🐛 fix: close regressions since 4.0.12 (#815)
  • 0712045 🐛 fix(read-write): refuse a database moved mid-acquire (#808)
  • 73fefc1 📝 docs: point canonical and og:url at versioned pages (#813)
  • 181b36b 🧪 test(lease): give the age-out test a real-time margin (#814)
  • 2c19af4 🐛 fix(api): release thread holds, guard reentry (#810)
  • 367b111 🐛 fix(soft-rw): publish the head through gen/HEAD (#799)
  • 61582c5 🐛 fix(api): validate lock options up front (#803)
  • 20c4b5a 🐛 fix(descriptor): reject poll intervals above TIMEOUT_MAX (#802)
  • cf092c7 🧪 test: drop timing races from two runner-load flakes (#809)
  • Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

@dependabot
Update filelock requirement from <4.1,>=3.4 to >=3.4,<4.2
5017ebe 
Updates the requirements on [filelock](https://github.com/tox-dev/py-filelock) to permit the latest version.
- [Release notes](https://github.com/tox-dev/py-filelock/releases)
- [Changelog](https://github.com/tox-dev/filelock/blob/main/docs/changelog.rst)
- [Commits](tox-dev/filelock@3.4.0...4.1.0)

---
updated-dependencies:
- dependency-name: filelock
  dependency-version: 4.1.0
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file python Pull requests that update python code labels Oct 18, 2026

This branch has not been deployed

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

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file python Pull requests that update python code

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants