Module lock 

One target held by one landing at a time.

A landing reads the target, decides against what it read, and writes. Two of them interleaved can each pass their own validation and then write over each other, leaving one landing’s files beside another’s receipt: a target describing a landing that never happened.

So a landing takes the target before its final evidence gathering and holds it through the receipt write. The lock is one file under the state root, named for the canonical target path, and what holds the target is the advisory lock the operating system puts on the open file, not the file’s existence. The kernel owns that lock: it releases when the holder exits, however it exits, so a run killed outright frees the target rather than stranding it. The file itself is left in place, because removing one another run has already opened would leave two runs holding locks on two different inodes under one name.

It lives outside the target because a target’s cleanliness is judged byte by byte, and a lock file inside it would be drift.

Where the lock cannot be taken, the landing refuses. A guard that silently does nothing is worse than none, because the call site still reads as guarded. It is advisory, and it bounds this binary’s own runs rather than every writer.

SATISFIES landing:a-partial-landing-is-visible-and-rerunnable

Structs

TargetLock

One target held for the life of this value.

Constants

LOCKS_DIR

The directory holding the locks, under the state root.

Functions

acquire

Take target for this run, or refuse.

acquire_in

The acquisition against one locks directory, which is what the tests drive so no test has to move the state root out from under itself.