LEARN. PRACTICE. GROW.Define a source and a reference
The runner creates a synthetic 234,256-byte file, a local area and an area served by sftp-server. The client uses -D to communicate directly with the local process through pipes. There is no SSH connection, authentication, host key or network. The source stays stable during tests and the runner computes hashes and compares bytes to check results. This preparation attributes differences to the tested operation. In a real service, the reference must be associated with delivery version and identity through the contract and a trusted source.
Resume when the prefix matches
The first partial copy contains the first 19,013 bytes of the known source. Reget completes the destination and exits zero. Full comparison confirms that the completed file matches the source. This shows a correct resume under controlled conditions: stable source and compatible prefix. It does not turn a filename into content identity. Before recovering a real delivery, identify whether the source was regenerated, whether the partial belongs to the same version and which check demonstrates that association, especially when partners reuse daily names.
Observe technical success with wrong content
The negative control creates a partial of the same length filled with Z bytes. Reget also exits zero and produces 234,256 bytes. However, the wrong prefix remains and only the suffix matches the source; the full hash differs. Size and zero exit therefore pass in both tests although only one result is correct. The experiment corrupts no real file. It demonstrates with synthetic data that resume assumes compatible existing content and that the wrapper needs an integrity criterion appropriate to the delivery.
Separate staging from publication
In the publication test, delivery.bin starts with an earlier version. Put writes new data to delivery.part, which the fictional consumer should ignore. Afterwards, the runner confirms the new hash in staging and the old hash under the final name. Only after rename does the partial disappear and the final name present new content; a get confirms byte equality. Logs show the posix-rename extension being advertised and used. Observation covers before-and-after states on one filesystem without testing concurrent readers, power failure or storage failure.
Do not equate publication with acceptance
The final name proves a technical stage in this experiment, not completed reconciliation. Define received, validated, published and accepted separately, in the order required by each system’s contract. If confirmation is lost, the consumer may already have processed the delivery. Query its identifier and state before repeating under another name because that can create a second logical delivery. Neither matching hashes nor rename semantics provide exactly-once business execution. The recovery plan should identify which evidence resolves uncertainty.
Decide near cut-off
In a fictional positions case, the partner regenerated the source, resume mixed versions and ten minutes remain before the deadline. Hold publication of content that failed comparison, confirm the intended version and assess a clean transfer or other authorized recovery. Communicate impact and decision ownership without changing the expected hash to make the result pass. The summary is to preserve identity and integrity throughout the stages. Urgency changes priority and communication, but it does not turn a mixed copy into a valid delivery.
# Actual local observations in content/labs/sftp-delivery/evidence.json
# validResume: exit 0, 234256 bytes, source hash matches
# wrongPrefixResume: exit 0, 234256 bytes, source hash differs
# publication: old final retained until rename; new final then matches
# No SSH transport or consumer is executedFictional case: two reget operations exit zero with 234,256 bytes. Only the partial with the correct prefix produces the source hash; the other copy is held from publication.
Common pitfalls
Accepting size and exit as integrity, resuming after regeneration without reconciliation, or treating rename and hashes as functional acceptance.
Related topics: Batch and observable failures · File publication and resumption · Diagnosis and RUN handover
Resume needs a compatible prefix; publication needs validated content; an accepted delivery needs consumer evidence.
Reference: OpenSSH SFTP client · BigSavant SFTP 2026-09; selected OpenSSH client, server and extension behavior