Storage resilience: atomic writes, safer temp cleanup, repair/restore tools

[KakashiTech]

Summary
OpenCode storage could be corrupted on crashes or disk-full mid-write. This proposes atomic writes, a safe repair routine, and a restore path to recover.

Problem

• Direct writes risk partial/truncated JSON.
• Leftover temps accumulate; repair lacked coarse-grained coordination and reporting.
• Operators need dry-run and limits before touching data at scale.

Proposal

• Atomic write: temp + fsync(file) + rename + fsync(dir).
• Repair: dry-run, prefix/limits, safe temp cleanup (.oc-*.tmp), skip-when-locked, JSON report.
• Restore: bring files back from quarantine preserving structure.
• Tests for dry-run/restore and temp cleanup.

Non-goals

• Schema-level validation or semantic corruption detection.
• Cross-FS transactional guarantees (e.g., NFS/Windows beyond documented best effort).
• Retention policy for quarantine (can be follow-up).

Risks/Trade-offs

• rename + fsync(dir) adds slight I/O overhead.
• Repair writes a report file (operationally useful).
• Try-lock may skip files busy during repair; reported as skipped.
• Portability: Bun APIs with Node fsync fallback; best-effort on non-POSIX FS.

Verification

• Unit tests added.
• Manual: run repair in a sandbox with XDG paths; confirm JSON report and quarantined files.

Open questions

• Retention policy for quarantine?
• Global maintenance lock for repair windows?

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• If disk space runs out your active session becomes corrupted #7607: If disk space runs out your active session becomes corrupted

The issue #7607 describes the exact problem this proposal aims to solve: corrupted JSON files when disk runs out of space mid-write. The proposed atomic writes and repair tools in this issue would directly prevent the situation described in #7607.

Feel free to ignore if this is intended as the implementation/solution issue for the problem described in #7607.

[KakashiTech]

Hiiii, whats up > I'll continue with: retrying/rollbacking when opening/renaming (treating sharing/UV_UNKNOWN violations as transient), quarantining and reporting if retries are exhausted, tolerant reads that redirect corrupted JSON to repair (without failures), and tests that simulate locked/truncated files. This should make storage robust even with antivirus blocks, i think so.