Module fsx 

fsx — the one atomic, durable file write for db.md’s primary data.

Every store-state file that holds primary data — content records (crate::parser::write_file), log.md and its archives (crate::log), and in-place link rewrites — is written through write_atomic or write_atomic_new:

1. write the bytes to a uniquely-named sibling temp file in the same directory (create_new, so a predictable temp name can never be clobbered — closing the temp-clobber race);
2. fsync the temp file;
3. either rename it over the destination (write_atomic) or hard-link it into place with create-new semantics (write_atomic_new);
4. fsync the parent directory so the committed directory entry survives a crash.

These are the only primitives for durable writes — never std::fs::write, which is neither atomic nor crash-durable. Use write_atomic when replacing an existing file is intended; use write_atomic_new when the destination must not already exist.

Not for the index. index.md / index.jsonl are derived, rebuildable artifacts on the O(changed) write-through path; they use their own atomic-but-not-fsync’d writer (crate::index’s AtomicTemp) on purpose — a crash-lost index write is recovered by dbmd index rebuild, so paying an fsync per catalog update on the hot loop would be cost without benefit.

Functions

write_atomic

Atomically and durably replace path with bytes (see the module docs for the write/fsync/rename/fsync sequence). The parent directory is created if missing. On any early return between temp-file creation and a successful rename — a write_all/sync_all failure (ENOSPC, EIO, quota) as well as a rename failure — the temp file is cleaned up rather than leaked, via the [TempGuard] Drop impl (mirroring index.rs’s AtomicTemp).

write_atomic_new

Atomically and durably create path with bytes, failing with std::io::ErrorKind::AlreadyExists if the destination already exists.