FTP frustration, xtra hard returns in my code

This is driving me absolutely insane, I want to choke someone or something.

Sometimes when I transfer files via FTP then open them in my editor there’s extra spaces, returns, in between the lines of code.

It apparently has nothing to do with binary or ASCII transfer modes and I can’t really pattern it. I just took a .TPL file extension and transferred it (downloaded) via ASCII, then Binary with the same result.

I’m using wsFTP Pro 6.70. I have it configured to transfer all the weird file extensions I use according to their content, ASCII or Binary, and all the accounts are set to ‘auto’ to detect transfer method as I’ve specified for each file extension.

Anyone know what could be causing this? It’s happened before but I suffered through it but I don’t want to mess with it again, it’s got me fuming.



You will need to add “.TPL” to the list of text files in WS_FTP, and make sure WS_FTP is set to “auto-detect”.

Windows use a CR/LF pair for the end of a line, while Linux uses just a LF. The extra lines are added when you upload a text file from a Windows computer to a Linux computer in binary mode, and download it back to the Windows computer in ASCII mode. The text file becomes corrupted because for each LF character in the file, ASCII mode puts a CR before it, whether or not there are any CR characters already before the LF character. The file remains corrupted until you remove the extra CR characters. To remove the extra CR characters, download the text file from the Linux computer as BINARY then upload it to the Linux computer as ASCII, and download to Windows computer again as ASCII.

Windows “text\CR\LF” (BINARY mode)-> Linux “text\CR\LF” = OOPS!
Linux “text\CR\LF” (ASCII mode)-> Windows “text\CR\CR\LF” = DOUBLE OOPS!
Windows “text\CR\CR\LF” (BINARY mode)-> Linux “text\CR\CR\LF” = TRIPLE OOPS!
Linux “text\CR\CR\LF” (BINARY mode)-> Windows “text\CR\CR\LF” = NOT OK YET
Windows “text\CR\CR\LF” (ASCII mode)-> Linux “text\LF” OK on Linux
Linux “text\LF” (ASCII mode)-> Windows “text\CR\LF” = OK on Windows

And, to add to the confusion, Apple systems (from the ancient Apple II to the latest MacOS) use CR by itself as the line break character, so that you can have even more wild and wonderful forms of file corruption if a Mac has been somewhere in the file’s history. (I think the Commodore 64 also used CR alone, along with even weirder perversions of ASCII, but that’s ancient history.)

Surprisingly, of all of these systems, it’s actually the ones from Microsoft that got the standards right (a rare thing for MS)… the traditional line break sequence, dating back to ancient Teletypes and continuing on mainframe systems like the DECSYSTEM-20, is CR+LF, with the CR signifying that the cursor should move to the start of the line and the LF indicating that it should jump down to the next line. The decoupling of the two operations instead of having one imply the other was one of those “seemed like a good idea at the time” things for the early standards-makers, as it enabled some special effects on Teletype terminals like using a CR without LF to overstrike things on the current line, but later programmers though it wasteful and decided the newline should be a single character, but couldn’t be consistent about which one, unfortunately.

– Dan

Excellent fellas, a thousand thank yous. You don’t know how hard that was to pattern, I reckon because of the upload/download/upload thing mentioned. That’s a relief.