0

Often, from different remote hosts, FileZilla will download a .cssor .php file and insert blank lines in between existing lines. This destroys nice formatting.

PC = Windows 10 Pro 64-bit.

How do I prevent this?

7
+25

My answer vs. OP's answer

I'm writing this answer when the solution has already been found by OP. The aim of my answer is to explain what the problem was to help future users with similar problems. Existing answer gives a solution but no insight. This is the answer:

Solution was to change the transfer type from Auto to Binary.

Transfer menu > Transfer type > binary


Problem background: ASCII vs. binary

As I suspected (in my comment to the question) the problem was a mismatch with line endings translation. The FileZilla Wiki covers the subject. These are the relevant fragments (all quotations that follow are from therein, some phrases are additionally emphasized by me):

Files can be transferred between an FTP client and server in different ways. The FTP specification (RFC 959) calls them "data type" (...)

The different data types are:

  • ASCII
  • binary
  • (...)

ASCII type is used to transfer text files. The problem with text files is that different platforms have different kinds of line endings. Microsoft Windows for example uses a CR+LF pair (carriage return and line feed), while Unix(-like) systems, including Linux and MacOS X, only use LF and traditional MacOS systems (MacOS 9 or older) only use CR. The purpose of ASCII type is to ensure that line endings are properly changed to what is right on the platform. According to the FTP specification, ASCII files are always transferred using a CR+LF pair as line ending.

So in case the file is transferred from the client to the server, the client has to make sure CR+LF is used. (...)

The same happens when a file is downloaded from the server to the client: the server makes sure the line endings are CR+LF when sending the file and the client then strips away whatever is not needed as line ending on its platform.

(...)

Compared to ASCII type, binary type is the easier one: the file is just transferred as-is, and no line ending translation is done.


What happened?

One of the examples when things go wrong matches the OP's case. I think this is what happened:

A Windows (CR+LF) text file was uploaded to a Unix-based FTP server in binary. If that file is downloaded in ASCII, the FTP server translates LF to CR+LF so the CR+LF line endings will be converted to CR+CR+LF. FileZilla on Windows does expect the file to already use CR+LF line encoding (per FTP specification), so no more translation is done. Depending on the text editor used, lines might be separated by an additional empty line now.


Solution

The OP's solution is to change the transfer type from Auto to Binary starting from Transfer menu. The article gives also other ways to change it:

You can change the transfer data type in three ways with FileZilla:

  • In the preferences of FileZilla
  • In the main menu under Transfer -> Transfer type
  • By right-clicking the data type indicator in the status bar of FileZilla.

Making binary the default option in Windows may lead to the situation when .css or .php or other text file downloaded from non-Windows system will be saved with single LF or CR instead of Windows-specific CR+LF. It may not be a problem, as explained in another fragment:

So when you are not sure what to use, always go for binary type. Nowadays, nearly all (good) text editors can handle the three possible line endings, and other textual files like the ones of scripting languages such as Perl or PHP, as well as XML files (nearly) always work with any line ending as well.

This solution may be the best in many cases because one can always change the transfer type.


Alternative solution

The question title suggests that additional lines were created by the OP's FileZilla. It is not true, there was nothing wrong with OP's FileZilla configuration. This problem originates on a server side where there are text files with line endings mismatching the server OS. The solution stated above is just a client side fix to the server side problem.

The alternative solution is to fix the files (their line endings) on the server side, so the ASCII transfer works as it should in the first place. This is obviously the right thing to do and may be called the best solution -- in a sense: because it deals with the root of the problem. Consider this solution if you administer the server or if you can contact the administrator or if you have rights to overwrite the ill-formatted file. This will benefit other users also.

Even if you contact the administrator, I think it is always faster to change transfer type and download the file you want instead of waiting for the changes to be made on the server side.

  • 1
    There is an additional solution: Fix the line endings on the server, so if it is a linux server change the line endings to be only LF. That way ASCII mode should translate everything correctly. – syntonym Jul 8 '16 at 8:00
  • @syntonym Thank you for pointing this out. I have updated my answer. – Kamil Maciorowski Jul 8 '16 at 9:01
0

Solution was to change the transfer type from Auto to Binary.

Transfer menu > Transfer type > binary

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.