anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 18:25:32 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

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

New Issue
Open
opened 2026-02-16 17:45:04 -05:00 by yindo · 2 comments
yindo commented 2026-02-16 17:45:04 -05:00
Owner
Copy Link
Copy Source

Originally created by @KakashiTech on GitHub (Jan 10, 2026).

Originally assigned to: @thdxr on GitHub.

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?
Originally created by @KakashiTech on GitHub (Jan 10, 2026). Originally assigned to: @thdxr on GitHub. 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?
yindo commented 2026-02-16 17:45:05 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 10, 2026):

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

  • #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.

@github-actions[bot] commented on GitHub (Jan 10, 2026): This issue might be a duplicate of existing issues. Please check: - #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.
yindo commented 2026-02-16 17:45:05 -05:00
Author
Owner
Copy Link
Copy Source

@KakashiTech commented on GitHub (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.

@KakashiTech commented on GitHub (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.**
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#4694
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?