Stop Filezilla from inserting blank lines in text files
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 the 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.
Solution was to change the transfer type from Auto to Binary.
Transfer menu > Transfer type > binary