Desktop atomic writes: fsync temp file + parent directory before/after rename for true crash durability

[qnbs]

Raised by chatgpt-codex-connector during the #354 review correction loop (thread: #354 (comment) area — see PR #354 for full context).

The gap

services/fs/fsCore.ts's writeTextFileAtomic/writeFileAtomic (added in #354) write to a temp file then rename over the final path, closing the "torn/partial write" class of bug. But in the abrupt power-loss scenario specifically, this isn't a complete durability guarantee: awaiting @tauri-apps/plugin-fs's writeTextFile/writeFile only completes the equivalent of write_all() — it doesn't call fsync/sync_all(), and a rename is not itself a durability barrier on most filesystems. The OS can still hold the new content (and the directory-entry update from the rename) in a page cache buffer that hasn't hit stable storage. A reboot at exactly the wrong moment could in theory expose an empty, partial, or still-the-old-file state despite the JS-level await having already resolved.

Why not fixed in #354

The real fix needs a Rust-side Tauri command (JS-level plugin-fs doesn't expose fsync control): open the temp file, write, sync_all(), close, rename, then open and sync the parent directory too (POSIX best practice for a rename to be durable, not just atomic). This is meaningfully more surface area than a JS-only PR — new Rust command, capability wiring, and it can't be meaningfully tested in this environment (no practical way to build/run a packaged Tauri desktop app here to verify real fsync behavior under simulated power loss).

Scope for whoever picks this up

• New Tauri command (e.g. write_file_durable) in src-tauri/src/commands/, wrapping write + sync_all() + rename + parent-dir sync.
• Register in lib.rs, wire capability permissions.
• Swap fsCore.ts's writeTextFileAtomic/writeFileAtomic to call it via invoke() instead of the plugin-fs JS API, on Tauri only (web build has no equivalent concept).
• Needs rust-check (PR ci: add required Rust/Tauri compile gate on pull requests #353's new CI gate) to at least catch compile/lint issues; real durability behavior can only be verified on a packaged build under actual (or simulated, e.g. SIGKILL mid-write in a controlled test) power-loss conditions.

Lower priority than the torn-write fix already shipped in #354 — this hardens an already-real improvement further, it doesn't fix a regression.

[qnbs]

Live status audit against main 34b83a22: services/fs/fsCore.ts#writeAndReplace writes a sibling temp file and renames it, but TauriApis exposes no file sync, sync_all, or parent-directory durability operation. PR #363 improves torn-write handling and atomic replacement, but does not prove crash durability. #357 therefore remains OPEN as a renderer-neutral Rust-Core storage requirement. Closure requires durable temp-file sync, atomic replacement, parent-directory durability where supported, and a controlled interruption/recovery test.

[qnbs]

R-15 / Rev-3 architecture reconciliation — 2026-08-24

The original issue correctly identified the durability gap, but its historical proposed fix is now too Tauri-specific to be the preferred target architecture.

Canonical ownership

#445 / R-15 is the integration authority. Implement the durable-write invariant in renderer-neutral/native Rust Core infrastructure wherever practical, then expose it through the typed native/DesktopPlatform contract consumed by Tauri during transition and Qt later.

Do not create a new long-lived Tauri-only write_file_durable authority merely because the original issue was reported against @tauri-apps/plugin-fs.

Required durability contract remains valid

Preserve the substantive requirement:

1. write/stage new content;
2. flush/sync file contents as required by the platform contract;
3. atomically replace/rename;
4. persist parent-directory metadata where required/meaningful;
5. report the exact durability boundary reached;
6. recover deterministic orphan staging/temp state;
7. preserve the previous valid authoritative record on failure where possible.

Platform-specific differences (including Windows semantics where directory fsync differs from POSIX) must be explicit rather than hidden behind a false universal guarantee.

Evidence

Headless Rust tests should cover ordering/error/failure-injection semantics. Packaged/native evidence is still required for platform filesystem integration and destructive lifecycle cases that unit tests cannot prove.

Closure rule

Close this issue only when #445 explicitly maps the durability acceptance criteria to implementation + tests/evidence. Do not close it merely because an atomic rename exists.

[qnbs]

Queue / execution status — 2026-09-05

Priority: P0 as an R-15 acceptance requirement. Canonical implementation owner: #445.

This issue preserves the crash-durability invariant originally observed on the transitional Tauri filesystem path. It must not be used to introduce a new standalone Tauri-only durable-write authority now that #445 owns renderer-neutral Rust/Core secure storage.

Keep the requirement: a protected authoritative write needs evidence for the admitted platform/filesystem durability contract (temp/staging write, required sync/flush, atomic replacement, directory metadata persistence where applicable, truthful failure/recovery semantics).

Close this issue only when #445's implemented Core path explicitly satisfies and tests/evidences this invariant. Historical threat detail in this issue remains useful provenance.