1

Recently I wasted almost two hours before realizing that the file upload with Filezilla corrupted the files (e.g. adding unwanted spaces or special UTF-8 characters being corrupted) after downloading and uploading files of a project from one server to local (Linux Mint) and up to another. While 99.9% of the files were totally o.k. I had this issues in very few files causing the project not to run anymore.

Lets assume I only have FTP connection available. I also prefer SFTP or even better SSH but some clients' hosts simply do not offer it. Therefore I wonder which is a SAFE way to transfer data via FTP which is probably encoded in different ways and contains different characters.

I have noticed that in Filezilla there is a setting for ASCII vs. binary mode. I found the following explanation:

There are two different modes for transferring files with FTP: "ASCII" and "binary" mode. The reason for the two different modes is that there are two distinct means of representing the end of a line in a text, or ASCII, file. On UNIX machines, the end of a line is represented by the character. This character is a control-J. Some UNIX commands, like od(1), represent this character with a "\n". For example, if you have a UNIX file named "foo":

$ cat foo this is a test of the terminal that is shot from guns. $ od -c foo 00000000000 t h i s i s a t e s t o 00000000020 f \n t h e t e r m i n a l t 00000000040 h a t i s \n s h o t f r o m 00000000060 g u n s . \n 00000000067

On PCs (and on Mainframe computers) the end of a line is represented by a followed by a character. This is a control-M followed by a control-J.

In FTP, if you specify "ASCII" mode, if you are sending a file from a UNIX system to a PC, a control-M will be added before every control-J in the file. This will ensure that the ASCII/text file will be readable on the PC. Conversely, if you send a file in "ASCII" mode from a PC to a UNIX system, the combination control-M control-J will get changed into a control-J. File size will decrease by one byte per line when sending from a PC to a UNIX system; file size will increase by one byte per line when sending from a UNIX system to a PC. When sending between two PCs -- or two UNIX systems -- files send in "ASCII" mode will be unchanged.

Files sent in "binary" mode are sent from one system to another with no modification. The file size will always be unchanged on a binary transfer.

"ASCII" mode is appropriate when using FTP to send a single text file between two PCs. "binary" mode is appropriate when sending anything else: TAR files, compressed files, gzip'd files, CA-Alexandria binaries, etc. If a binary file is sent between a PC and a UNIX system in "ASCII" mode, the contents of the binary file will be modified such that it will no longer be readable; the file will have to be re-sent from the originating system in binary mode. Typically, this is the source of the problem when a customer sends us TAR or compressed files that are not readable on our machines.

Additionally, everyone should remember that since our ftp site is an NT server, the default transfer mode is ascii. Our typical customer is a UNIX sys admin. They are used to sites that default to binary. When asking them to put files on our site, remind them that it defaults to ascii and that they will want to set binary mode.

(Source: https://knowledge.broadcom.com/external/article/28212/ftp-ascii-vs-binary-mode-what-it-means.html)

According to this I assume that binary mode is always a safe way to go while ASCII mode may cause various problems? Is my assumption correct and are there any further settings to consider (e.g. regarding charset) in order to avoid issues like this with FTP GUI clients in the future?

4
  • 3
    I feel there's no reason for the ASCII mode to exist anymore. It's probably there for historical reasons. A file transfer protocol should not care about the contents of files nor alter it. – SparedWhisle Aug 20 '20 at 10:52
  • 2
  • 2
    Any eol conversions will not affect UTF encoding ... – DavidPostill Aug 20 '20 at 10:55
  • Thanks for the clarifications so far! – Blackbam Aug 20 '20 at 12:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.