In the example above, the file newthisweek.Z was transferred, but supposedly not correctly. The reason is this: in a normal ASCII transfer (the default), certain characters are translated between systems, to help make text files more readable. However, when binary files (those containing non-ASCII characters) are transferred, this translation should not take place. One example is a binary program—-a few changed characters can render it completely useless.
To avoid this problem, it's possible to be in one of two modes—-ASCII or binary. In binary mode, the file isn't translated in any way. What's on the remote system is precisely what's received. The commands to go between the two modes are:
ftp> ascii 200 Type set to A. (Note the A, which signifies ASCII mode.)
ftp> binary 200 Type set to I. (Set to Image format, for pure binary transfers.)
Note that each command need only be done once to take effect; if the user types binary, all transfers in that session are done in binary mode (that is, unless ascii is typed later).
The transfer of newthisweek.Z will work if done as:
ftp> binary 200 Type set to I. ftp> get newthisweek.Z 200 PORT command successful. 150 Opening BINARY mode data connection for newthisweek.Z (42390 bytes). 226 Transfer complete. local: newthisweek.Z remote: newthisweek.Z 42390 bytes received in 7.2 seconds (5.8 Kbytes/s)
Note: The file size (42390) is different from that done in ASCII mode (42553) bytes; and the number 42390 matches the one in the listing of UUNET's top directory. We can be relatively sure that we've received the file without any problems.
mget and mput
The commands mget and mput allow for multiple file transfers using wildcards to get several files, or a whole set of files at once, rather than having to do it manually one by one. For example, to get all files that begin with the letter f, one would type