How FTP works
FTP session state and roles
Follow the user and server protocol interpreters, transfer processes, login state, and working directories.
FTP is not a series of independent requests like a simple HTTP download. The server keeps session state, and later commands depend on earlier ones.
Think of it like a phone call where you set context once and keep talking. You do not re-introduce yourself before every sentence unless the call dropped. Same with CWD and TYPE. A fresh login resets everything.
After you log in, the server remembers your user, current directory, transfer type, and the data endpoint you picked. Drop the connection and you lose all of that context. There is no cookie. You rebuild from USER and PASS.
Type these commands on a test server and watch how each line changes what the next command means:
ftp> type i
200 Type set to I
ftp> cwd releases
250 Directory changed
ftp> epsv
229 Entering Extended Passive Mode (|||50022|)
ftp> get app.tar.gz
150 Opening BINARY mode data connection
226 Transfer completeget app.tar.gz now means “download releases/app.tar.gz as binary bytes through the passive port you just opened.” Reconnect and you must run type i, cwd releases, and epsv again before the same download works.
Renaming is a two-step state machine on the wire:
ftp> rnfr notes.txt
350 Ready for destination name
ftp> rnto notes-backup.txt
250 Rename successfulSend any other command between rnfr and rnto and the rename breaks.
If you run two scripts on one FTP session, one script can change the directory underneath the other. Give each job its own connection.
Idle timeouts can drop the control channel while you still think you are logged in. The next command may return 421. Reconnect and rebuild state. I keep a checklist on my desk for that rebuild.
Write down the session state after each line in the first example. Then reconnect and list which commands you must repeat.
Lesson completed