Problem

Several finally blocks call fcntl.flock(fd, LOCK_UN) without catching OSError. If the unlock fails (e.g., fd already closed, NFS stale handle, signal interruption), the exception propagates and skips subsequent cleanup code — most critically fd.close(), which leaks the file descriptor and leaves the lock held indefinitely.

The msvcrt (Windows) path is already guarded with try/except OSError in every case, but the POSIX fcntl path is not. This asymmetry means the bug only manifests on Linux/macOS.

Fix

Wrap each fcntl.flock(fd, LOCK_UN) call in try/except OSError: pass, matching the existing guard on the msvcrt path.

Fixed Sites

Before vs After

# BEFORE — OSError skips close(), lock held forever
finally:
    fcntl.flock(lock_fd, fcntl.LOCK_UN)   # raises OSError
    lock_fd.close()                        # NEVER REACHED

# AFTER — unlock failure is tolerated, close() always runs
finally:
    try:
        fcntl.flock(lock_fd, fcntl.LOCK_UN)
    except OSError:
        pass
    lock_fd.close()                        # always reached

Tests

All 4 modified files compile cleanly (python3 -m py_compile). The fix is purely defensive — no behavioral change when flock succeeds.