AIKIDO-2026-190770

TL;DR

filelock's Unix backend opens the lock file with O_TRUNC and calls fchmod before it confirms exclusive access through fcntl.flock, so any process attempting to acquire the lock, including one that ultimately fails to get it, first truncates and re-permissions the file the current holder relies on. The Windows backend has a parallel timing gap: its reparse-point check runs against the lock path rather than the already-opened handle, so the path can be swapped to a symlink between the check and the open. Both gaps let a co-resident process on the same lock directory corrupt or redirect another process's lock state while that process still believes it holds exclusive access. The fix defers file mutation until after the OS lock is confirmed and binds the Windows reparse check to the opened handle.