On Windows, "ReadWriteLock" and "AsyncReadWriteLock" (the SQLite-backed reader/writer lock) connect SQLite to the lock database by its path, in every directory. SQLite derives three side files from that path: "<database>-journal", the rollback journal (pages saved to undo an interrupted write); "<database>-wal", the write-ahead log (changes kept outside the main file); and "<database>-shm", the shared-memory index of the WAL. SQLite acts on whichever of these it finds beside the database before the lock runs any statement. Another local account that can create files in the database's directory, but not delete files of other accounts there, places such a side file beside the database and denies everyone "DELETE" on it, which a file's creator may do. "C:\Windows\Temp" (the temporary directory of services, granting "BUILTIN\Users" create but not delete) and "C:\Users\Public" are such directories. With a "-wal" in place, every "read_lock()" and "write_lock()" of the user running the lock (below: the lock user) raises "sqlite3.OperationalError: disk I/O error" at once, whatever "timeout" says, until that account removes its file; the lock user cannot. With a "-journal" beside a lock database that holds a table, SQLite replays the journal and deletes the file the journal names, a file of the lock user, and the acquire reports success. Affected versions are filelock 3.20.4 through 4.2.0 on Windows. The maintainers found this while reviewing the fix for the POSIX form of the defect, GHSA-v4x8-3wr5-3wq8, whose text says "Windows does not take this path" (review round 4, finding F2 of set D). It is not among the findings of the report Anthropic's OSS Scanner sent on 15 October 2026.