[kevinmdavis]

A package-backed file opened to be modified copies its content into memory, and tarfs took empty memory to mean the file was still the package's. A file truncated to empty through OpenFile then read back the package's content, at the package's size, so the truncation was lost.

A node now records that it was opened to write, and from then on its content is what is in memory, even when that is nothing.

[codysoyland]

Automated review by unblok using Codex · gpt-6-astra · medium reasoning effort

Agent recommended action: Request changes

Requesting changes: a failed writable open can permanently hide the package file's content.

Worth fixing

• Commit the written state only after buffering succeeds: pkg/tarfs/fs.go:429.

What I verified

• At a2abe68, a backing reader returning zero bytes and an error makes OpenFile(O_RDWR) fail, but the next ReadFile succeeds with empty content and Stat reports zero. The same reproduction against the base returns the original eight bytes.
• The written check at pkg/tarfs/fs.go:409 prevents recovery after that failure; Size uses the same state at pkg/tarfs/fs.go:999.
• TestTarFSTruncatePackageFile covers successful truncation and subsequent content/size, but not a failed backing read.

[codysoyland]

Automated review by unblok using Codex · gpt-6-astra · medium reasoning effort

Re-reviewed after e060645. LGTM.

Addressed: failed backing read now leaves the node unchanged; pkg/tarfs/fs.go:427-434 commits data and written only after success.

What I verified

• The error return at pkg/tarfs/fs.go:428 precedes both node mutations, including when ReadAll returns partial data.
• Ran TestTarFSPackageFileReadFailure at e060645: passed. It checks preserved content and size, a successful writable retry, and unchanged backing content.
• Re-ran my original zero-byte read-error reproduction at e060645: subsequent ReadFile returns the original eight bytes and Stat reports size eight.