Module atomic_write 

Atomic file replacement: write to a temporary file in the destination directory, then rename it into place.

Rename within a directory is atomic on POSIX, so a reader never observes a half-written TZif file, and an interrupted run leaves either the old file or nothing — never a truncated one. The temp file is created in the same directory as the target so the rename stays within one filesystem (cross-device renames fail).

The durability contract (T17.4), three layers — claimed exactly, not more:

1. content fsync — the temp file’s bytes are sync_all’d before the publish, so the published name never points at unflushed content.
2. atomic publish — hard_link (exclusive create, default) or rename (--force) makes the name appear (or replace) in one step; a reader/crash never sees a partial file.
3. directory-entry fsync — when durable is set (the install path, not ephemeral scratch), the parent directory is fsync’d after the publish, so the new directory entry itself survives a crash. Without this layer a crash after the rename can still lose the entry on some filesystems (the file content was durable, but the link to it was not).

What this does NOT claim (RISK.INSTALL.1): a whole-tree crash-atomic install. Each file is durably published, but a crash mid-run can leave some files published and others not — there is no tree-level transaction. Directory-entry fsync is a Unix guarantee (opening a directory and sync_all-ing it); on non-Unix it is a documented no-op, so the durability claim is Unix-scoped.

Functions

write_atomic

Atomically write bytes to target.