Repository navigation
Storage resilience: atomic writes, safer temp cleanup, repair/restore tools #7733
Description
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?
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Jan 11, 2026
This issue might be a duplicate of existing issues. Please check:
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 commentedon Jan 28, 2026
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.
github-actions commentedon Apr 12, 2026
To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.