fix: write write_file and disabled_extensions.json atomically

[matiaspalmac]

[Fix]: Write write_file and disabled_extensions.json atomically

Description

Two call sites used fs::write (equivalently std::fs::write)
directly:

• apps/desktop/src-tauri/src/lib.rs — the write_file Tauri command
  used by the frontend editor/save path.
• apps/desktop/src-tauri/src/extensions.rs — the
  disabled_extensions.json write inside toggle_extension_state.

A crash or power loss partway through either call left the target
truncated — enough to corrupt whatever the user had been saving
and, in the extensions case, to break extension loading on the next
launch because the registry file was no longer valid JSON.

Change

Added a small new module apps/desktop/src-tauri/src/fs_atomic.rs
exposing write_atomic(path, bytes). Both call sites now go through
it.

Behavior of write_atomic

1. Write payload to a hidden sibling temp file named
   .<target_name>.<pid>.<nanos>.tmp. Placing the temp next to the
   target keeps the rename on the same volume (the atomicity
   guarantee is per-volume), and the leading . + PID/timestamp
   keeps editors and file-watchers from surfacing it.
2. sync_data() the temp file before the rename, so the data has
   actually reached disk rather than merely the OS page cache.
3. std::fs::rename(tmp, target):
   • On POSIX rename is atomic at the filesystem level.
   • On Windows it maps to MoveFileEx with
     MOVEFILE_REPLACE_EXISTING | MOVEFILE_WRITE_THROUGH, which
     performs the replacement atomically on NTFS for same-volume
     targets.
4. On any failure along the way (temp create, write, sync, rename),
   the temp file is cleaned up best-effort so the target directory
   doesn't accumulate .tmp leftovers.

Tests

cargo test fs_atomic covers three cases:

• Writes a brand-new file — target didn't exist before.
• Replaces an existing file's contents — target existed with
  different bytes.
• Leaves no .tmp leftovers — sibling directory is clean after
  a successful write.

All three pass on Windows; the module has no platform-specific code
beyond what std::fs::rename already abstracts.

Trade-offs

• Filename format. A PID+timestamp suffix is enough uniqueness to
  avoid collisions between concurrent saves of the same file without
  pulling in tempfile. If two processes ever share an IDE state
  directory (they shouldn't), the nanosecond timestamp still avoids
  clashes.
• Same-volume only. If the target sits on a different volume
  than the temp (e.g., a user's file on a network drive), the rename
  will fail and return an error; the original file is preserved. A
  cross-volume fallback (copy + delete) would not be atomic anyway,
  so I deliberately did not add one — a loud error is preferable to
  a silently non-atomic path.
• No metadata preservation. write_atomic does not currently
  carry over mode bits / ACLs from the previous file. Both call
  sites write JSON or plain text that's owned by the IDE process,
  so this hasn't caused behavior differences in practice. If a
  future caller needs preservation we can extend the helper rather
  than every call site.

Verification

• cargo check → clean.
• cargo clippy --tests -- -D warnings → clean.
• cargo test fs_atomic → 3/3 pass.
• Manual trace of both call sites:
  • write_file("C:\\…\\note.txt", "hello") → temp next to target,
    rename succeeds, target now contains hello, no .tmp files
    remain.
  • toggle_extension_state(id, false) then _state(id, true) →
    disabled_extensions.json valid JSON after both operations, no
    intermediate truncation observed even when hitting the process
    with taskkill /F mid-toggle.

Related Issue

Fixes #77

Checklist

• I have tested this on the latest version.
• I have followed the project's coding guidelines.
• My changes generate no new warnings or errors.
• I have verified the fix on:
  • OS: Windows
  • Version: v1.0.10

[github-actions]

Thanks for the contribution! I'll review it as soon as possible. If you have still changes, please mark this PR as draft and all reviews will be cancelled. Tests reviews will be re-run only when the PR is marked as ready for review.

[Copilot]

Pull request overview

This PR introduces an atomic write helper for the Tauri backend to prevent file truncation/corruption on crash or power loss, and wires it into the write_file command and the extensions registry (disabled_extensions.json) write path.

Changes:

• Add fs_atomic::write_atomic(path, bytes) helper that writes to a sibling temp file, syncs it, then renames over the destination.
• Update write_file to use write_atomic instead of std::fs::write.
• Update toggle_extension_state to write disabled_extensions.json via write_atomic.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
apps/desktop/src-tauri/src/lib.rs	Registers the new module and routes write_file through atomic writes.
apps/desktop/src-tauri/src/fs_atomic.rs	Implements atomic write helper and adds unit tests.
apps/desktop/src-tauri/src/extensions.rs	Routes disabled_extensions.json updates through atomic writes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Hi @matiaspalmac, the quality checks have failed.

❌ Quality Checks Failed

Check	Status
Dependencies	✅ Success
Lint	✅ Success
Typecheck	✅ Success
Clippy	✅ Success
Format	❌ Failure

Full Log (Format)

Diff in \\?\D:\a\ide\ide\apps\desktop\src-tauri\src\fs_atomic.rs:112:
         let leftovers: Vec<_> = fs::read_dir(&dir)
             .unwrap()
             .filter_map(|e| e.ok())
-            .filter(|e| {
-                e.file_name()
-                    .to_string_lossy()
-                    .ends_with(".tmp")
-            })
+            .filter(|e| e.file_name().to_string_lossy().ends_with(".tmp"))
             .collect();
         assert!(
             leftovers.is_empty(),

View full logs