Download, upload, and change files

File bytes move on the data connection. Replies stay on the control connection. Wait for the final reply before you treat an upload or download as done.

That split confuses people who expect one HTTP request and one response. FTP gives you 150 while bytes move, then a separate final code when the server finishes its bookkeeping.

I watch both codes in scripts. Some clients surface only the last one and hide the preliminary reply. Log both when you automate. The preliminary 150 tells you the data channel opened.

get downloads (RETR). put uploads (STOR). delete removes a file (DELE). Renaming takes two steps on the wire: RNFR selects the source, then RNTO sets the new name. The interactive rename command wraps that pair.

Upload to a temporary name first. I do this on every production upload:

ftp> put release.zip release.zip.part
150 Opening data connection
226 Transfer complete
ftp> rename release.zip.part release.zip
350 Ready for destination name
250 Rename successful

The 226 means the bytes landed. The 250 means the rename finished. Those are two separate checks. Do not announce the release after 226 alone.

Downloads look similar:

ftp> get report.csv
150 Opening data connection
226 Transfer complete

put can overwrite an existing file depending on the server. Do not assume a failed upload left the old copy intact until you test that host.

append (APPE) is risky in scripts. A retry can duplicate bytes at the end of the file.

Create a folder when you need one:

ftp> mkdir staging
257 "/incoming/staging" created

Before delete, run pwd and list the directory. FTP has no undo. I type the filename twice before I confirm.

Try this on disposable files. Pull the network cable mid-upload and confirm release.zip never appeared while release.zip.part did.