Context
A configuration writer uses a temporary file and rename so readers never see a partially written document. The system crashes, and the newest configuration is missing after reboot. Atomic visibility and durable storage are different properties. A correct file-publication design needs to establish both according to the filesystem, operating system, and storage guarantees involved.
Separate the two questions
Linux documents rename semantics for replacing a pathname and fsync semantics for flushing file data and metadata. The fsync manual specifically notes that syncing a file does not necessarily persist its containing directory entry; the directory may need an explicit sync as well. Review these guarantees for the actual filesystem and storage stack.
Atomic replacement addresses what concurrent readers observe at the pathname boundary. Durability addresses what survives a crash after the application reports success. A design can provide one without the other. State which guarantee the application needs before choosing an implementation.
An illustrative configuration publisher
Imagine a service generating a new routing configuration. It writes a temporary file, renames it over the active path, and returns success. The machine loses power immediately afterward. On restart, the expected revision is absent, even though readers before the crash saw a complete file.
The incident record should distinguish publication time, reported success, sync results, filesystem, mount configuration, and recovery state. Do not infer a storage failure merely because the application omitted the durability steps required by its own success contract.
Use a controlled replacement sequence
A common design writes a temporary file on the same intended filesystem, validates its content, establishes the required file metadata, flushes the file as needed, replaces the target through supported rename semantics, and persists the directory change as required. Every step needs error handling.
Use a unique temporary name and avoid unsafe assumptions about shared writable directories. Handle ownership and permissions before making the candidate active. A complete file with overly broad permissions is still an incorrect publication.
Check filesystem boundaries
A temporary directory on another filesystem can change replacement behaviour. An operation that appears to be a simple move may become a copy-and-delete sequence in higher-level tooling. Review the actual API and filesystem relationship rather than inferring atomicity from the command's name.
Test network filesystems and layered storage separately. Their guarantees and failure behaviour can differ from a local filesystem. Use the documented semantics of the actual deployment and avoid a universal claim based on one developer workstation.
Preserve error information
Check write, flush, close, rename, and directory-sync outcomes according to the language and API. Errors can surface after the initial write call. A helper that suppresses a flush error may report success before durable publication is established.
Define what the caller should do after an uncertain outcome. It may need to read the active revision and compare it with the intended operation. Do not retry blindly if the operation includes other side effects or if the candidate's identity is no longer known.
Coordinate multiple writers
Atomic replacement does not decide which of two complete candidate files should win. If several writers can publish concurrently, define ownership or a version check. Otherwise, an older computation can replace a newer result even though every individual rename is atomic.
Include a revision identifier inside the document and validate the expected previous revision where the architecture supports it. For strongly coordinated multi-writer state, a database or another transactional store may be a more appropriate tool than a growing collection of file-level conventions.
Test readers and crash recovery
Run concurrent readers while repeatedly publishing validated candidates. Confirm readers observe complete recognised revisions rather than truncated content. Then perform controlled crash testing in an appropriate disposable environment.
Test failures after writing, after file sync, after rename, and before directory sync. Inspect the recovered state and compare it with the application's documented success boundary. A normal process exit test is not equivalent to a power-loss or kernel-crash exercise.
Quick diagnostic map
| Evidence | Interpretation | Next check |
|---|---|---|
| Readers see complete old data after crash | Durability boundary incomplete | Inspect sync results |
| Replacement crosses filesystems | Atomicity assumption invalid | Check temporary location |
| Older complete revision wins | Multiple writers uncoordinated | Enforce publication order |
A focused operator exercise
Create a disposable test publisher with versioned complete documents and concurrent readers. Record the actual filesystem, temporary-file location, replacement API, and success boundary. Verify readers see recognised complete revisions while candidates are written and replaced. Include permission and ownership checks so publication correctness covers access as well as content.
Inject process failures around write, flush, close, rename, and directory persistence, checking every returned error. Then perform controlled crash testing appropriate to the storage environment. Compare recovered revisions with what the application had reported as durable. Keep normal process termination and storage-crash evidence separate because they exercise different guarantees.
Add two competing publishers and verify the ordering or ownership rule prevents an older candidate from replacing an accepted newer state. Test abandoned temporary-file cleanup without deleting an active candidate. The exercise passes when visibility, durability, concurrency, and rollback each have a stated guarantee and observed result, with no universal claim inferred from one successful rename.
Keep rollback and cleanup distinct
Retaining a previous known-good revision can help application recovery, but it does not replace durability. Document how rollback selects a revision and publishes it through the same supported mechanism. Clean abandoned temporary files using a policy that cannot delete a live candidate.
Monitor publication failures and adopted configuration revision. A writer's success log and the consumer's active revision should be reconcilable. This helps distinguish durable publication from a consumer that failed to reload the new file.
Clouvenix can help review file-based configuration and artifact publication against the actual Linux storage guarantees. The result is a success contract that says exactly what readers can see and what the application expects to survive a crash.
Frequently asked questions
Does rename make file contents durable?
Atomic pathname replacement and persistence are separate concerns. Follow the required write and sync sequence for the actual filesystem and check every result before claiming the intended crash-survival guarantee.
Can two writers safely publish because replacement is atomic?
Readers may avoid partial files, but competing complete writes still need an ordering or ownership rule. Define which revision may replace which state and prevent stale writers from winning accidentally.
Explore Clouvenix linux administration for implementation and operational handover.