The lifecycle of one transfer

First the client selects active or passive mode. Then it sends a transfer command such as RETR.

A preliminary reply such as 150 says the server is opening the data connection. Bytes move on that connection. Closing it marks the end of data, and the control connection receives a final reply such as 226.

A complete data stream without a successful final reply is not enough. The server may have detected a write, policy, or filesystem error after receiving bytes.

The control transcript should bracket the data operation:

C: EPSV
S: 229 Entering Extended Passive Mode (|||50010|)
C: RETR archive.tar.gz
S: 150 Opening BINARY mode data connection
...data socket reaches EOF...
S: 226 Transfer complete

The client can fail at several independent points: endpoint negotiation, TCP connection, preliminary authorization, byte transfer, or final server completion.

For downloads, write to a local temporary file. Rename it only after the expected byte count or hash and the final successful reply. For uploads, apply the same pattern on the remote side when the server supports rename.

A timeout after data EOF but before 226 is uncertain. The server may have completed the operation. Inspect remote state before blindly retrying an append or destructive action.

Interrupt the example at each stage and predict the visible local and remote files. Verify the prediction against a disposable server.