Uploading file removes ALL carriage returns screwing up files

[Kev]

Im kinda just about to give up with filezilla :( doesnt happen all of the time but 60% of the time when i upload a php file that ive just edited using the left click edit or left click open save then upload pops it over to the server but all the code ends up on one line completely screwing up the php because all the code after the comments is classed as comments, tried many work arounds and it doesnt work.

To make things even nicer, sometimes when i open files from the server they have an extra line or 2 between every line of code, whats happening? this has happened on the latest 3 versions ive downloaded.

Cheers guys / gals :)

[Tim Kosse]

Check your data type, you're most likely transferring the files with the wrong data type.

Besides, since nobody else seems to have this problem, setting this to critical is a blatant lie.

[James]

I have the same problem. It is completely intermittent and I have changed no settings...

[odys]

Same behavior as #5486 (​http://trac.filezilla-project.org/ticket/5486) added by me. I gave more info there, I found this latter.

I do not like the attitude of "codesquid". He HAS a problem, and so am I.
In auto and ascii transfer mode, files are indeed changed. If you download them they will have an extra [CR] carriage return, and if you manually remove extra lines (using notepad++ for example) the "normal file" that had its empty lines removed, will become an ONE LINE document after uploading. I can verify this. It doesn't happen all the time and I cannot replicate it.

Please show some respect to the bug reporters, we are not from your team but not your enemies.
We can work together, and why not joining your team at some point.

If possible, merge with #5486 or mark this as duplicate.

[Tim Kosse]

This isn't a bug, it's desired and useful behavior that is part of the FTP specifications. On top of it, there is an option to toggle which data type is used for transfers.

[indigo]

For the benefit of anyone like me who finds this after having experienced exactly the same issue, I believe I have a more rigorous explanation for exactly what's going on. Codesquid posted a link on #5486 that provides all of the relevant information, which I shall re-post here for convenience:

​http://wiki.filezilla-project.org/Data_Type

The bug appears to lie in the standard itself, rather than Filezilla specifically. That is, the actions defined to ensure that \r\n line endings are always transmitted and then converted by the receiver to whatever is appropriate for that platform may fail if the source file itself has the wrong line endings for the client platform. For example (assuming one transfers the file using the ASCII data type):

IF: a file with CR-only line endings is uploaded
FROM: a windows client
TO: a linux server
THEN: the transmitted file will only feature CRs, which will be deleted
RESULTING: in a file with no newlines

Which is very bad news if your file contains line comments, since this will effectively change its meaning. Similarly,

IF: a file with Windows line endings (CR+LF) is downloaded
FROM: a Linux/Mac server
TO: a Windows or Mac/Linux client
THEN: additional unwanted CR/LFs will be inserted
RESULTING: in a file with mixed or double newlines

Other scenarios of this type can clearly be concocted, but I would have thought these two would be the most common. As codesquid pointed out, the data type can be specified for transfers. In the absense of a parser in Filezilla to handle malformed newlines, the only safe answer appears to be to use the binary type for all transfers.

[filezillabug]

Agree, I'm having the same issue all the time in different forms (either too many new lines or everything compressed into 1 line). This happens during download or upload from/to server.

Are there any settings that we should give files (prepared in Notepad++) to avoid that? They have [Edit > EOL Conversion > Windows/UNIX/Mac] - which one should we pick?

[Alexander Schuch]

Another section is available in ​http://wiki.filezilla-project.org/Data_Type. It covers the example given by indigo.

If you are on Windows, and need to upload files in ASCII, make sure line endings are CR+LF (Windows). I never used Notepad++, but if you want to be sure, count the number of occurrences of LF, of CR and of CR+LF. If you get the same number in all three cases, the file should be "safe" to upload in ASCII.

[filezillabug]

Just FYI:

1) Uploading Windows or Mac line ending from Windows to linux server and downloading it back again results in:
a) 2 times more lines
b) no new lines

2) Doing the same using FTP Synchronize for Notepad++ or Total Commander (data type set to "automatic" in all cases) results in flawless/correct line endings.

It's easy to test all cases...
a) Windows line ending
b) Mac line ending
c) UNIX line ending
1a) Windows computer
1b) Mac computer
2a) Windows server
2b) Linux server
There are like 20+ situations to test. The most common ones like downloading UNIX file to Windows computer fail (results in 2x more lines).

[filezillabug]

Mac file on server: 86,204kb

Downloading Mac file from server to Windows 7: 87,810kb (+ 2 times more lines)

[Alexander Schuch]

Can you please provide logs?

ASCII mode transfers automatically handle the line endings. Are you sure you upload and download files in ASCII mode? Are you sure that you use the native line ending in your local editor and not a mix (which most editors gracefully handle)?

[Alexander Schuch]

No reply for more than 28 days.