Integration gap
When upgrading the Poe agent-service VFS to safe-bash/safe-fs 0.1.549, ordinary zip /bundle.zip /a fails with:
zip: ZIP publication requires atomic owned file staging
The RPC-backed adapter implements bounded reads/writes, exclusive creation, and atomic rename, but does not yet implement createStagedFile/publishStagedFile/removeStagedFile and the associated ownership/identity contracts. This is a host capability gap, not evidence that ZIP is corrupting archives. The failure is explicit and safe.
Please provide a documented supported integration path or reusable adapter for RPC-backed filesystems, with a conformance suite for owned staging and extraction. We should wire real server-side atomic operations and preserve standard ZIP behavior; do not emulate atomic staging with unguarded read/write/rename sequences or change command semantics. The Poe integration work can then adopt that contract.
Separately, #723 tracks missing standard zip -q and unzip -p flags. Initial ZIP support was #687.
csplit needs the corresponding conditional-mutation contract
The same adapter cannot run csplit /input 2: it reports atomic output mutations are not supported. It requires atomicFileMutation plus writeFileConditional/removeFileConditional. Please cover this in the documented RPC-host integration and conformance suite as well; avoid implementing it as non-atomic client-side read/modify/write or delete.
Temporary product integration
The product owner explicitly requested that ZIP creation/extraction and csplit work now using non-atomic operations. The agent-service adapter therefore composes snapshot checks and bounded RPC writes/renames as a temporary implementation. The capability flags admit the commands but do not provide transaction isolation across shell calls. Sequential archive round trips, binary extraction, splitting, partial-output cleanup, and Worker execution are covered by integration tests.
This issue remains open to replace that temporary composition with genuine server-side transactions and a supported ownership/identity contract. The earlier request to avoid non-atomic emulation describes the desired permanent solution, not a blocker for the temporary product integration.
Integration gap
When upgrading the Poe agent-service VFS to safe-bash/safe-fs 0.1.549, ordinary
zip /bundle.zip /afails with:The RPC-backed adapter implements bounded reads/writes, exclusive creation, and atomic rename, but does not yet implement
createStagedFile/publishStagedFile/removeStagedFileand the associated ownership/identity contracts. This is a host capability gap, not evidence that ZIP is corrupting archives. The failure is explicit and safe.Please provide a documented supported integration path or reusable adapter for RPC-backed filesystems, with a conformance suite for owned staging and extraction. We should wire real server-side atomic operations and preserve standard ZIP behavior; do not emulate atomic staging with unguarded read/write/rename sequences or change command semantics. The Poe integration work can then adopt that contract.
Separately, #723 tracks missing standard
zip -qandunzip -pflags. Initial ZIP support was #687.csplit needs the corresponding conditional-mutation contract
The same adapter cannot run
csplit /input 2: it reportsatomic output mutations are not supported. It requiresatomicFileMutationpluswriteFileConditional/removeFileConditional. Please cover this in the documented RPC-host integration and conformance suite as well; avoid implementing it as non-atomic client-side read/modify/write or delete.Temporary product integration
The product owner explicitly requested that ZIP creation/extraction and csplit work now using non-atomic operations. The agent-service adapter therefore composes snapshot checks and bounded RPC writes/renames as a temporary implementation. The capability flags admit the commands but do not provide transaction isolation across shell calls. Sequential archive round trips, binary extraction, splitting, partial-output cleanup, and Worker execution are covered by integration tests.
This issue remains open to replace that temporary composition with genuine server-side transactions and a supported ownership/identity contract. The earlier request to avoid non-atomic emulation describes the desired permanent solution, not a blocker for the temporary product integration.