Should all(most) calls that write files follow writeAtomically pattern ?

[alexbozhenko]

Proposed change

I stumbled upon this blog post:
https://hypermode.com/blog/alice/
that describes a tool(blog post author's fork) that records system calls to ensure that the order of the calls would result in safe atomic file operations.

Then I found that the tool is actually based on the paper that
@sciascid mentioned in #7388 (comment)

Alice itself did not build for me on the first try, but feeding docs to Claude gave me the following. These are valid concerns, aren't they?

Non-Atomic File Overwrites

Multiple places use os.WriteFile() that overwrite files in-place instead of temp-file-and-rename:

• filestore.go:1372 - recoverFullState() - overwrites message block
• filestore.go:1404 - convertToEncrypted() - in-place encryption conversion
• filestore.go:8939 - Compact() - overwrites compacted block
• filestore.go:10130 - writeFullState() - overwrites index.db (critical metadata)

Impact: Crash mid-write → corrupt files → data loss

---

Missing Directory Sync After Rename

Classic ALICE bug - os.Rename() without syncing parent directory:

• filestore.go:5329 - tryForceCompressBlock() - compress block rename
• filestore.go:6713 - atomicOverwriteFile() - encryption/compression update
• filestore.go:8734 - Purge() - purge rename
• filestore.go:9815 - Delete() - delete rename

Impact: Crash after rename → directory metadata not persisted → file gone or both old/new exist

---

Missing fsync Before Rename

filestore.go:5323-5329 - tryForceCompressBlock() writes file then renames without sync:

os.WriteFile(mfn, nbuf, defaultFilePerms)  // no fsync!
os.Rename(mfn, mb.mfn)

Impact: Rename succeeds but data still in cache → crash → empty/partial file

Use case

No data loss on crashes.

Contribution

No response