At 09:37 AM 4/13/07, stuart van Zee wrote:
Sorry if this belongs elsewhere but I was sure someone here would know.
I was under the impression that when using SFTP to transfer files they
were automatically treated as Binary files. So if the remote file uses
CRLF to terminate lines, the downloaded file would have CRLF terminating
it's lines. So I have a vendor that has replaced his FTP with SSH/SFTP.
my code is written to expect CRLF because that is the way the files
were when using the old FTP system to download. Now, when I use SFTP
the files just have the LF. The vendors answer is that we need to use
ASCII mode to transfer the files to get the CRLF. I didn't know that
there WAS an ASCII mode in SFTP let alone that using ASCII as opposed to
Binary would change the line terminators. The files in question are
technically ASCII text files but shouldn't I be getting an EXACT copy of
the file when I use Binary mode (assuming that I am right and that is
indeed the default with SFTP)?
What I really need is an explanation or a pointer to where I can get an
explanation so that I really know what I am talking about when I talk
to this vendor (and KNOW that I know what I am talking about).
FTP and SFTP clients will often have an option to send files as
ASCII/BINARY/AUTO. This option controls how CRLF is handled when
encountered in the source file. This option has nothing at all to do with
the FTP/SFTP protocol itself; but is an option often included in client
software.
When transfer option is ASCII (or sometimes TEXT); a translation
occurs. When copying from Windows to *BSD, CRLF changes to LF. When
copying from *BSD to Windows, LF changes to CRLF.
When transfer option is BINARY; no translation ever occurs.
When transfer is AUTO; behaviour is either ASCII or BINARY depending on
file extension. TXT, HTM, PHP, CGI, PL might all be considered text files;
client software often allows this list to be configured.
PSCP and WinSCP are two examples of windows software that support
SFTP. PSCP does not convert CRLF to LF; WinSCP has a user option
controlling this translation.
Based on what your vendor says; it looks like the file originally contains
only LF and not CRLF; so enabling ASCII transfer should convert LF to
CRLF. If your transfer software doesn't have this option find another that
does.
