Transfer behavior
ASCII and binary transfer types
Use TYPE I for byte-for-byte transfers and understand the historical newline conversion performed by TYPE A.
Before a transfer, set the transfer type. TYPE A is ASCII mode and can change line endings. TYPE I is binary mode and moves bytes exactly as they are on disk.
I use TYPE I for almost everything: images, zip files, PDFs, SQLite databases, and UTF-8 text. ASCII mode on a binary file can corrupt it without an obvious error. The file size might even look close to right.
Many clients pick binary automatically. Still check the setting in automation scripts and old interactive clients. A wrong type is a common reason two copies of the same file hash differently.
The interactive ftp client shows the current type when you run type with no argument. Do that before a big transfer if you are unsure.
Set binary before you download:
ftp> type i
200 Type set to I
ftp> get database.sqlite
150 Opening BINARY mode data connection
226 Transfer completeImage mode does not mean the file is a picture. It means “do not touch the bytes.”
ASCII mode can convert \n to \r\n and back:
ftp> type a
200 Type set to A
ftp> get README.md
150 Opening ASCII mode data connection
226 Transfer completeTransfer the same README on macOS and Windows in ASCII mode and the hashes can differ even when the text looks identical.
If a zip file will not open after download, check the transfer type first. Switch back with type i and download again before you blame the archive.
Size and resume offsets depend on the type too. Set binary before you compare SIZE output with a local file length.
Transfer one small text file in both modes between systems with different newline habits. Run shasum -a 256 on each copy and compare the digests.
Lesson completed