create: do not wrap repository writes in backup_io("read") (silent data loss on ENOSPC)

[ThomasWaldmann]

What

borg create on an out-of-space repository could silently commit a corrupt, unrestorable archive and exit 0 with a normal success summary.

Symptom

On a repository whose backend runs out of space during borg create:

• create prints a normal summary — Added files: N, Error files: 0 — and exits 0.
• The committed archive references chunks that were never durably stored. Afterwards:
  • borg check → Missing file chunk detected (exit 1)
  • borg compact → Repository has N missing objects! (exit 2)

So a backup reports success but is not restorable.

Root cause

process_file() ran process_file_chunks() inside with backup_io("read"):

with backup_io("read"):
    self.process_file_chunks(item, cache, ..., backup_io_iter(self.chunker.chunkify(None, fd)))

That block is meant to guard reading the source file, but the source reads are already guarded individually by backup_io_iter(). The outer wrapper additionally caught add_chunk()'s repository writes. So a critical repository IO failure (e.g. ENOSPC during a pack flush) was wrapped into a per-file BackupOSError, tagged "read" — indistinguishable from "this source file couldn't be read". Borg then only warned, skipped the file, continued the walk, and create_inner() committed the archive via archive.save(). Because pack flushing is deferred, chunks of earlier, already-emitted items were lost too, so the whole archive ends up referencing missing chunks.

This directly contradicts the BackupOSError docstring:

These are non-critical and are only reported (warnings). Any unwrapped IO error is critical and aborts execution (for example repository IO failure).

Fix

Drop the outer backup_io("read") wrapper. Source reads stay per-file warnings (backup_io_iter is unchanged); repository OSErrors are now left unwrapped and therefore critical, aborting create before archive.save() runs — as the docstring prescribes.

Audited all with backup_io blocks across src/borg: this regular-file path was the only one wrapping a repository operation. The stdin/pipe and import-tar process_file_chunks call sites were already unwrapped (correct).

Testing

• archive_test.py (40) and create_cmd_test.py (61) pass.
• Reproduced on a space-limited macOS ramdisk (source data > free space), across a create/delete/compact churn matrix (24/32/64/96 MB, varied data):
  • Before: over-full creates exited 0 with corrupt archives; compact then reported Repository has N missing objects! and check reported missing chunks in every run.
  • After: over-full creates fail (exit 2) and commit nothing; the repository stays consistent (check: no problems found) in every run. Normal backups and unreadable-source-file handling (per-file warning) are unchanged.

Notes / follow-ups (not in this PR)

• The abort currently surfaces as a traceback (Error: OSError: [Errno 28] …) plus a secondary FileNotFoundError during unwind, rather than a clean Error: No space left on device. Worth polishing (catch the repo OSError → clean Error, make PackWriter/close() teardown ENOSPC-clean).

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.11%. Comparing base (a8c2c7b) to head (5aaa2dd).
⚠️ Report is 14 commits behind head on master.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #9853      +/-   ##
==========================================
- Coverage   85.11%   85.11%   -0.01%     
==========================================
  Files          93       93              
  Lines       15409    15408       -1     
  Branches     2326     2326              
==========================================
- Hits        13115    13114       -1     
  Misses       1596     1596              
  Partials      698      698              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.