LEARN. PRACTICE. GROW.Concept and mechanism
A consumer reading as soon as the final name appears can observe a file still being built. Agree on an ignored temporary area or name and a publication step after validation. If that step uses rename, check implementation, extension, and filesystem. The OpenSSH posix-rename extension has POSIX semantics differing from the basic operation in protocol versions; do not claim universal atomicity for every SFTP server. In the documented POSIX case, source and destination must share a filesystem. Copying between filesystems does not automatically preserve the same properties. The consumer contract should define when processing may start and how it identifies each delivery.
Guided application
Resuming a transfer also has assumptions. If the source was regenerated and its prefix changed, continuing over an old partial copy can combine incompatible versions. Reconcile content before deciding on resumption or a new delivery. Flushing after upload depends on extension support and outcome in the OpenSSH fsync example; storage persistence does not prove business validation or processing. In a reconciliation scenario, separate received, published, validated, and accepted milestones. If a response is lost after publication, retain delivery identity and consult consumer state before repeating. Transport encryption does not provide exactly-once processing.
Persisted file and business-accepted file are different milestones.
Common pitfalls
Final name as ready; universal rename; resumption with changed source; flush as reconciliation; timeout as no effect.
Related topics: Transport and server trust · Permissions and isolation · Batch and observable failures
Define publication and recovery as explicit producer-consumer contracts.
Reference: OpenSSH implementation protocol extensions · DR SFTP 2026-09; selected OpenSSH client, server and extension behavior