up vote 2 down vote favorite
share [g+] share [fb]

Using the FTP command I transferred an xml file from a Red Hat Enterprise Linux box which happens to be in Europe to another RHEL box in the United States. I didn't specify a transfer mode so it defaulted to ASCII which as far as I understand shouldn't ever translate characters between two Linux boxes, but it did. The file size grew at the destination and vim reported it as a DOS file. I checked and LANG=en_US.UTF-8 on both machines.

Anyone have a clue why this character translation happened?

link|improve this question
Not programming-related - belongs on superuser ? – Paul R Mar 1 '10 at 21:19
Think this belongs on superuser – t0mm13b Mar 1 '10 at 21:22
Think this belongs somewhere between Super User and Server Fault personally. – Dominic Rodger Mar 1 '10 at 21:24
@Dominic: Either of those would have been better than posting on a programming site, since the question has absolutely nothing to do with programming. – Ken White Mar 1 '10 at 21:31
feedback

migrated from stackoverflow.com Mar 1 '10 at 21:34

This question came from our site for professional and enthusiast programmers.

2 Answers

That's exactly what ASCII mode does. It translates line ends.

If you don't want that, simply switch to BINARY mode, which transfers the data as-is without any transformation.

These days you hardly ever want ASCII mode at all. Especially not for XML files.

link|improve this answer
I think the point here is that it was two Linux boxes. Why would it translate the line endings to DOS format? – Troubadour Mar 1 '10 at 21:20
1  
@Troubadour:using <CRLF> for line endings predates DOS. RFC 765 specified it for text mode ftp in 1980, roughly a year before the IBM PC first hit the market. – Jerry Coffin Mar 1 '10 at 21:28
Yes, that was the point of the question. – Steve Prior Mar 1 '10 at 21:28
feedback

RFC 959 says that when sending in ASCII mode, the sending side must send the file in a "standard form" with CRLF line-ends, and the "receiver will convert the data from the standard form to his own internal form." (See section 3.1.1.1, ASCII Type.)

So it appears that in your case, the sending side sent the file with CRLF line-ends because the FTP protocol requires it, and the receiving side is keeping them for some reason.

I found the following page that says by default, the FTP server in Red Hat Enterprise Linux 3 and 4 pretends to allow ASCII mode, but preforms a binary transfer anyway: Why does the vsftp FTP server fail to transfer a file in ASCII mode when ASCII mode has been set by the FTP client in Red Hat Enterprise Linux 3 and 4?

So that might explain why it's keeping the CRLF line-ends.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown

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