LEARN. PRACTICE. GROW.Validate the version before validating transport
A correct transport can deliver the wrong file for the business period. relativeWrongSource starts in a stale directory containing delivery.csv from an earlier version. Put uses a relative name and exits zero, with a remote hash matching the selected source. The error precedes transport: the contract expected the file from the expected directory. explicitSource uses an explicit path from the same starting directory and sends the intended version. This comparison shows why an operator-terminal test is insufficient for the scheduler. Record resolved path, period, delivery identity, and expected hash. A stable path can contain different content; confirmation needs to connect the selected artifact with the business cycle.
Publish a state the consumer understands
In roundtrip, upload writes stage.part and leaves the previous final file unchanged. Another session requests rename and downloads the result; complete comparison confirms the observed bytes. The test covers before-and-after states, not concurrent readers, business transactions, or persistence under failure. renameDenied demonstrates an important intermediate state: staging is complete, but the final name is absent. The scheduler must not turn that failure into success if the contract uses the final name as the availability signal. Preserve identity, hash, and useful artifacts while reconciling recovery. Do not impulsively delete staging or create another delivery identifier; resend safety depends on the consumer contract. Report received bytes and ready delivery as separate conditions.
Separate capabilities, requests, and guarantees
The client can report server-supported extensions, but extension availability does not prove operation authorization. The rename control applies a policy that can refuse publication after a valid upload. flushRequest uses put -f and diagnostics record Sending SSH2_FXP_EXTENDED(fsync@openssh.com). Read content matches the source and the transfer completes normally. This demonstrates the request and observed content without a power-loss experiment, storage recovery, or consumer confirmation. Upload flush behavior depends on extension support. Document the endpoint’s actual capability and the evidence needed for its durability commitment. Do not turn a fault-free local result into a universal zero-loss guarantee. Keep transfer acceptance and resilience acceptance separately traceable in the change record.
Prepare a decision and RUN handover exercise
The guide below proposes forty minutes of practice: eight to identify delivery, twelve to locate failure, twelve to decide recovery, and eight to prepare acceptance. Use Ria to compare same-named files with different versions; Farol to distinguish filesystem permissions from read-only subsystem policy; and Duna to decide about complete staging without publication. One participant represents APS, another the integration owner, and another the change manager. The final decision should include owner, permitted operation, expected evidence, deadline, and reversal condition. These cases are fictional and do not represent BNP Paribas policies. The guide has not yet been executed with participants. The lab teaches local mechanisms; real acceptance requires authorized job context, endpoint, and consumer. The report should separately preserve demonstrated criteria and criteria still dependent on observation in the authorized environment.
FORTY-MINUTE GUIDE: SFTP AND ACCEPTANCE
Fictional cases without real-bank policies.
Copy run.py from the preceding lesson. Python 3, POSIX, and a usable non-root local account.
Seven matching OpenSSH 10.5p1 binaries; executed build excludes PAM.
Replace /path/to with authorized paths. The system SSH service is not used.
python3 run.py \
--ssh /path/to/openssh-10.5p1/ssh \
--sshd /path/to/openssh-10.5p1/sshd \
--sshd-session /path/to/openssh-10.5p1/sshd-session \
--sshd-auth /path/to/openssh-10.5p1/sshd-auth \
--keygen /path/to/openssh-10.5p1/ssh-keygen \
--sftp /path/to/openssh-10.5p1/sftp \
--sftp-server /path/to/openssh-10.5p1/sftp-server \
--output evidence.json
0–8: identify version, resolved path, recipient, and delivery identity.
8–20: Ria sends an old version; Farol rejects writing; Duna retains staging.
For each case: stage, evidence, hypothesis, and missing confirmation.
20–32: decide recovery, owner, access boundary, and retry risk.
32–40: define acceptance operation, expected result, and reversal condition.
Deliver a table covering source, transfer, publication, and consumption.
Distinguish an fsync request from evidence of surviving power failure.
No external partner, chroot, network interruption, or real consumer was tested.
Guide has not yet been executed with participants.
Ria proves received bytes match the source but discovers that source belongs to the previous day. It corrects selection and reconciles the consumer before resending.
Common pitfalls
Treating zero status as the correct version, using a hash without an expected reference, confusing an fsync request with physical-failure testing, or reporting success after refused rename.
Related topics: Incident and change management · Integrations and idempotency
Delivery acceptance combines intended version, integrity, publication, and consumer contract. Each conclusion must match evidence actually collected.
Reference: OpenSSH SFTP client · BigSavant SFTP 2026-09; selected OpenSSH client, server and extension behavior