After os.Rename returns nil, what still has to be synced for the new file to survive a power loss?

## What a successful rename does and does not promise The temp-file-and-rename idiom buys *visibility* atomicity: no process ever observes a partially written file at the target path. That guarantee holds against concurrent readers. It does not hold against the machine losing power, because everything so far may still be sitting in the operating system's page cache. A crash discards that cache. What comes back after the reboot is whatever the filesystem had actually committed, in whatever order it chose to commit it. There are two separate pieces of state at risk, and they need two separate syncs. ## Sync the file's data, before the rename `f.Sync()` on the temp file asks the kernel to push that file's data (and enough metadata to find it) to stable storage, and to report an error if it cannot. It must happen **before** the rename, and the ordering is the whole point. A filesystem does not promise to commit a file's data before it commits an unrelated metadata change. If you rename first and sync afterwards, there is a window where the target name has been committed while the data blocks behind it have not. Come back from a crash and the config file exists, has the right name, and is empty or full of zeros - which is worse than a missing file, because a reader will happily parse it and find nothing. Syncing first means the sequence of durable states is: (old file, no temp) -> (old file, complete temp) -> (new file). Every one of those is a state a reader can cope with; the middle one just leaves litter. ## Sync the parent directory, after the rename The rename does not modify the file - it modifies the *directory* that contains the name. A directory is metadata, and metadata is cached too. If the machine dies after the rename returns but before that directory change is committed, the reboot can produce the pre-rename directory: the target still names the old file, and your publish silently did not happen. Nothing is corrupt, but a controller that reported success has lied. Making the swap durable means fsyncing the directory itself. In Go that is: ```go d, err := os.Open(filepath.Dir(path)) if err != nil { return err } defer d.Close() if err := d.Sync(); err != nil { return err } ``` `os.Open` on a directory returns an `*os.File` you cannot read bytes from, but whose `Sync` reaches the underlying handle, which is exactly what is wanted. This is a POSIX-shaped concern: on Linux and the BSDs it is the documented way to make a directory entry durable, and on Windows the durability model is different enough that portable code usually guards the step. ## What each omission looks like in a postmortem - **No file sync at all**: after an unclean shutdown the config exists but is empty or truncated; the sidecar fails to parse it and the node never becomes ready. This is the failure people remember, because it is permanent - nothing will rewrite the file until the controller notices a change. - **File synced, directory not**: after the crash the file is simply the old version. Confusing rather than fatal, and easy to misdiagnose as "the controller didn't run", because there is no corrupt artefact to find. - **Sync after the rename instead of before**: the rarest and the nastiest, because it is timing-dependent and passes every test on a machine that never crashes. ## How to actually test it Reasoning is not enough here; the ordering bugs only appear under a crash. A crash-injection harness is the honest test. Run the writer as a child process, kill it uncatchably at a chosen point - after the write, after the sync, after the rename - then re-open the target from the parent test and require that it parses as *either* the old document or the new one, never anything else. Loop over the injection points, and loop each point many times. Killing the process only exercises the case where the process dies, not where the machine does, so a thorough version pairs it with a filesystem or device that can be told to drop unsynced writes. ## The cost, and when to skip it Both syncs are real I/O and can dominate the cost of writing a small file. For a config file rewritten when desired state changes, that is irrelevant - it happens rarely and correctness is the entire point. For a hot path writing thousands of small files a second, the same pattern will show up as latency, and then the decision is explicit: batch the writes, sync once per batch, or accept that the last few writes are lossy and say so in the design. What you must not do is skip the syncs silently and describe the result as crash-safe.