I think I understand the difference between ASCII mode and Binary mode on regular FTP transfers — in Binary mode the file is copied exactly, and in ASCII mode the client may modify line endings (stripping the Carriage Return from Windows -> UNIX or adding it in the other direction). However, I thought that the SFTP protocol only supported Binary mode style transfers; the source file would not be modified.
However, when using the JSch library to copy a file from Windows to UNIX, the Windows-style line endings are stripped. This is problematic because these files are retrieved by others, using various methods, for Windows machines, and I can’t guarantee that their clients will re-add the Carriage Return before each Line Feed.
Properties properties = new Properties();
properties.setProperty("StrictHostKeyChecking", "no");
Session session = jsch.getSession(UserName, Address, Port);
session.setPassword(Password);
session.setConfig(properties);
session.connect();
ChannelSftp channel = (ChannelSftp)session.openChannel("sftp");
channel.connect();
channel.
channel.cd(SCPDir);
channel.put(new ByteArrayInputStream(WindowsStyleString.getBytes()), FileName);
channel.disconnect();
session.disconnect();
Is there something I can do to ensure that JSch transfers the files exactly? It is frustratingly lacking in documentation, so I’m not sure if there’s some parameter of its or perhaps some additional SSH property I can specify to ensure verbatim transfer. And why is this even happening in the first place, when ASCII mode style modifications aren’t part of the SFTP standard?
SFTP supported only binary mode until version 4 and in version 4 and later (5, 6) binary mode is still default, though ASCII mode is available too. Whatever JSh does with your file is it’s own initiative. Maybe it strips CRs itself, or maybe the server does this, I can’t say for sure without seeing any kind of log that Jsh or server exposes.