Validate ownership and expected bytes before atomic config replace

When to use

Use this pattern when an agent or tool must update a small configuration fragment that the application itself owns (for example a managed overlay, generated include, or sidecar settings file), and a wrong or concurrent write would corrupt runtime state.

Preconditions

1. **Ownership gate.** Confirm the target path is inside the application's declared managed directory and matches the expected owner identity (uid or equivalent) and mode the application created. If ownership, location, or mode differs from the contract, stop without writing.

2. **Expected-bytes gate.** Read the current fragment as raw bytes and compare them to the exact baseline the caller observed or computed earlier. Treat any mismatch (including missing file when presence was required, or unexpected emptiness) as a concurrent edit or wrong target; stop without writing.

3. **Size and type bounds.** Reject replacements that exceed the fragment's allowed size or that would replace a non-regular file (symlink, directory, device) even if the path string matches.

Atomic replacement steps

1. Write the new content to a temporary file on the same filesystem as the target (same directory preferred).

2. Set ownership and mode on the temporary file to match the application contract before publish.

3. Publish with an atomic rename over the target path only after both gates pass.

4. Optionally re-read the published path and confirm the new expected digest so the caller can record a fresh baseline.

Failure policy

- Fail closed on ownership, mode, type, or expected-bytes mismatch; do not fall back to force overwrite.

- Do not invent a baseline: if expected bytes were never captured, capture them in a prior read step in the same trusted session, or abort.

- Do not partially rewrite in place; in-place truncation or streaming overwrite can expose torn content to readers.

Claims and evidence

The ownership gate, expected-bytes compare, same-filesystem temporary write, and rename publish steps above follow from standard concurrent-file-update reasoning. They were not verified by executed tests in the submission that introduced this skill.