The disagreement that causes silent corruption
On Windows, a process that opens a file for writing typically acquires an exclusive lock automatically. The operating system enforces this at the kernel level: a second process attempting to open the same file will receive an error, not silent access. The locking is mandatory — no participant can opt out.
POSIX systems, including Linux and macOS, take the opposite default. A file opened for writing remains accessible to every other process that asks. Locking exists — the flock and fcntl interfaces both provide it — but it is advisory. Two processes that both choose to respect advisory locks will coordinate correctly; one process that ignores them breaks the contract for everyone, and the kernel will not intervene.
The core contrast
FROM THIS ENTRY| Windows file locking | mandatory, kernel-enforced, automatic on open |
|---|---|
| POSIX file locking | advisory, cooperative, ignorable by any process that chooses not to participate |
flock / fcntl | the POSIX interfaces that provide advisory locking |
A Windows program running through a compatibility layer carries the mandatory-locking assumption baked into its behaviour. It may never call any explicit lock API at all, because on its native system the kernel already guarantees exclusivity. Translated to a POSIX host, that guarantee disappears. The program holds the file open and assumes it is safe; another process — or another instance of the same translated program — walks in through the unlocked door.
The compatibility layer has to manufacture the missing guarantee. It intercepts file-open calls, maintains an internal table of which paths are currently held under what access modes, and refuses a conflicting open in the same way the Windows kernel would. This works correctly as long as every participant goes through the layer. A native POSIX process that opens the same file independently will bypass the table entirely, because the host kernel does not know the table exists.
This is not a flaw in the translation so much as a statement about what translation can and cannot reach. The layer can only audit the calls it sees. Anything that arrives at the host filesystem by another route — a file manager, a backup daemon, a second terminal window — plays by POSIX rules and stays invisible to the compatibility logic. Mandatory locking, in this sense, is a social contract that requires every participant to agree. Translated programs bring their side of the contract across; the host system never signed it.
Where the layer breaks down
FROM THIS ENTRY| The compatibility layer's internal lock table | effective only for calls the layer intercepts |
|---|---|
| Native POSIX processes | bypass the table; the host kernel has no record of the translated lock |
| The boundary of what translation can guarantee: only what passes through it |
Shimwork is an independent publication about compatibility layers. It is not a software vendor, distributor, or support service.