Exclusive sibling temp, durable flush, and abort unlink for fragment publish

When to use

Use after ownership, expected-bytes, size, and type gates have already decided that an application-owned configuration fragment may be replaced. This procedure covers only the temporary-file publish path: how to create it, make it durable, publish it, and clean it up on abort.

Do not use this as a substitute for those gates, for writer compare-and-swap, or for hard-link semantics. Ordinary rename still only replaces one directory entry.

Exclusive sibling temporary

1. Create the temporary in the same directory as the target so rename stays on one filesystem and one directory inode.

2. Use an exclusive create (create-new, fail if the name exists). Do not open-truncate a fixed well-known temporary name shared across writers or retries.

3. Prefer an unpredictable suffix per attempt so a concurrent writer cannot predict and occupy the name you intend to use.

4. If exclusive create fails because the name exists, choose a new name and retry create; do not fall back to truncating the colliding path.

Reasoned example: two writers both prepare publish against the same managed fragment and both open a temp named fragment.tmp for truncate-write. Either may clobber the other's bytes before rename. Exclusive create-new on distinct names avoids that collision class. This example is reasoning, not an executed test.

Ownership and mode on the temporary

Apply the application contract owner and mode to the temporary after write and before publish, matching the target contract used by the earlier ownership gate. If those metadata updates fail, abort and unlink the temporary; do not rename a file that violates the contract.

Durable flush before rename

1. After writing the full replacement bytes, flush the temporary file data to stable storage (file sync or equivalent required by the platform).

2. Where the platform documents it, also flush the parent directory so the directory entry for the temporary is durable before rename.

3. Only then rename the temporary over the target path.

Reasoned example: a writer renames immediately after write returns, then the host loses power. Readers may later observe a zero-length or partially persisted fragment at the published name even though the rename appeared to succeed. Flushing before rename narrows that crash window for the temporary's bytes. This example is reasoning, not an executed test.

Boundary: pre-rename flush is not entry durability

Pre-rename file and directory flush makes the temporary's bytes and its temporary directory entry more durable. It does **not** by itself make the replacement directory entry crash-durable after rename returns.

After a successful rename, flush the parent directory again (where the platform documents directory sync) so the published name durably points at the new inode.

Concrete reasoned case: the writer flushes the temporary, renames over the live fragment name, then the host crashes before a post-rename parent-directory flush. On recovery the directory may still name the prior inode, so readers reopen the old fragment while the new bytes exist only on an unlinked inode. Treat pre-rename flush alone as insufficient for that entry-durability goal. This case is reasoning, not an executed test.

Non-goals for this boundary: post-rename directory flush does not prove durability on every filesystem, does not serialize competing writers, and does not replace ownership or expected-bytes gates.

Abort unlink and failure policy

- If any gate fails after the temporary exists, or if metadata, flush, or rename fails, unlink the temporary you created. Do not leave orphan temps in the managed directory.

- Do not invent rollback of an already-successful rename by guessing prior bytes. If post-publish verification is used and the published digest is unexpected, treat that as concurrent publish or wrong target, stop further writes, and report; recovering prior content requires a separately retained baseline, not an orphan temporary that was already renamed away.

- Do not partially rewrite the live target in place as a recovery shortcut.

- Do not claim exclusive temporary create serializes competing renames; it only protects the temporary name itself.

- Do not claim pre-rename flush already covered replacement directory-entry durability.

Claims and evidence

The exclusive-create, same-directory rename, durable-flush-before-publish, post-rename parent-directory flush boundary, and abort-unlink steps follow from standard concurrent-file-update and crash-durability reasoning, including maintenance conversation evidence on this skill. No executed tests were run for this update.