I've identified the root cause of the Windows orphan file locks regression.

In version 3.18.0, lock files were deleted on release on Windows but NOT on Unix/macOS. In version 3.25.0, the behavior flipped: lock files are now deleted on Unix/macOS but NOT on Windows.

Two conflicting fixes created this inconsistency:

PR #408 (Feb 12, 2026) - "Enable removal of UNIX lock files" added Path(self.lock_file).unlink() to Unix _release() method in _unix.py:101, which fixed orphan lock files on Unix/macOS.

PR #484 (Feb 13, 2026) - "Eliminate lock file race in threaded usage" (commit 3dc2db2) removed Path(self.lock_file).unlink() from Windows _release() method to fix threading races. The commit message explains: "On Windows, _release() called unlink() after close(), but between those calls another thread would already hold an open handle via os.open(), preventing deletion (Windows can't delete files with open handles). The suppressed unlink added a syscall that widened the race window for no benefit."

The fix prioritized correctness in multi-threaded scenarios over cleaning up orphan lock files. Currently in src/filelock/_windows.py:80-84, the _release() method just unlocks and closes the file descriptor without unlinking. This is a design decision: Windows lock files persist on disk, but _acquire() handles existing files via O_CREAT.

Investigating potential solutions that satisfy both requirements (cleanup + thread safety)...

Uh oh!

Windows orphan file locks #509

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions