Upload without exposing partial files

Uploading directly to a public filename can expose a partial file to another process. A safer pattern is to upload to a temporary name and rename it only after a successful transfer.

Wait for the final FTP completion reply. When integrity matters, compare a cryptographic hash through a trusted side channel or supported server extension; file size alone cannot prove equal content.

FTP rename semantics depend on the server filesystem, so test the workflow you depend on. The protocol does not make a multi-file deployment atomic.

Treat publication as a small state machine:

local source
  -> STOR release.zip.part
  -> final 226
  -> verify size or trusted hash
  -> RNFR release.zip.part
  -> RNTO release.zip
  -> final 250

Use a unique temporary name so two uploaders do not overwrite the same partial object. Clean abandoned temporary files with a bounded retention policy, not by deleting every name ending in .part.

A hash protects integrity only when the expected digest arrives through a trusted path. A hash downloaded beside the file over the same compromised cleartext FTP session does not detect an attacker who can replace both.

The final rename may be atomic on one server filesystem, but FTP does not promise that across directories, mounts, or storage backends. A group of files also needs a release pointer, manifest, or server-side deployment mechanism if readers must see one consistent version.

Run the sequence with a deliberate mid-upload disconnect and a deliberate hash mismatch. Confirm that neither failure replaces the public file.