EldoS | Feel safer!

Software components for data protection, secure storage and transfer

TElSimpleSFTPClient ASCIIMode not working

Posted: 08/29/2007 10:47:22
by David Talby (Standard support level)
Joined: 08/29/2007
Posts: 2

Hello. I'm using TElSimpleSFTPClient the same way as the sftp sample application except that I'm setting ASCIIMode to true. But I'm still seeing binary transfers (i.e. no line-ending conversions on my uploaded text files). The server does support setting the text mode, and I can do ASCII transfers just fine to the server in WinSCP. Do you have any suggestions for how to troubleshoot this? Here is the code where I set up the client:

// Set all of the properties the same way it's done in the SBB sample application for sftp.
TElSSHMemoryKeyStorage KeyStorage = new TElSSHMemoryKeyStorage();
client.KeyStorage = KeyStorage;
client.ASCIIMode = true;
client.AuthenticationTypes = 4;
client.AutoAdjustTransferBlock = true;
client.CertAuthMode = SBSSHClient.TSBSSHCertAuthMode.camAuto;
client.ClientHostname = "";
client.ClientUsername = "";
client.CompressionLevel = 6;
client.DownloadBlockSize = 8192;
client.ForceCompression = false;
client.LocalAddress = null;
client.LocalPort = 0;
client.NewLineConvention = null;
client.PipelineLength = 32;
client.SftpBufferSize = 131072;
client.SFTPExt = null;
client.SocketTimeout = 0;
client.SocksAuthentication = 0;
client.SocksPassword = "";
client.SocksPort = 1080;
client.SocksResolveAddress = false;
client.SocksServer = null;
client.SocksUserCode = "";
client.SocksVersion = 1;
client.SoftwareName = "EldoS.SSHBlackbox.5";
client.SSHAuthOrder = SBSSHCommon.TSBSSHAuthOrder.aoDefault;
client.UploadBlockSize = 32768;
client.UseInternalSocket = true;
client.Username = "";
client.UseSocks = false;
client.UseUTF8 = true;
client.UseWebTunneling = false;
client.Versions = ((short)(28));
client.WebTunnelAddress = null;
client.WebTunnelAuthentication = 0;
client.WebTunnelPassword = null;
client.WebTunnelPort = 3128;
client.WebTunnelUserId = null;

(Plus authentication, host, and port stuff.)
Posted: 08/29/2007 11:23:53
by Eugene Mayevski (Team)

1) please ensure that you are using the latest build of SecureBlackbox. There were some improvements made just recently (in build 118).
2) check that the negotiated version of STP protocol is 4 or later. ASCII mode is not supported in STP 3 and before.
3) please specify the name of the server sotware which is supposed to support the text mode. It's possible that WinSCP emulates the text mode itself.

Sincerely yours
Eugene Mayevski
Posted: 08/29/2007 16:10:39
by David Talby (Standard support level)
Joined: 08/29/2007
Posts: 2

You're right, it was the protocol version. The servers I was hitting were using a surprisingly (to me) old version of OpenSSH. I guess I'll have to emulate the text mode myself.

Posted: 03/14/2008 15:44:03
by Justin Bourlier (Standard support level)
Joined: 02/29/2008
Posts: 2

I can't get this to work either. I'm using version I *think* the negotiated protocol is "2". I got this by looking at FClient.Version property after connecting (see ex below). After further investigation using a hex editor, I noticed that file before being sent has lines ending with LF, but after uploaded, they contain CR LF.


I've also tried reading the file in as bytes, then writing to the file on the server using the Write method (saw a similar example on another thread).

i.e. (C#)
byte[] handle = client.OpenFile(saveTo, SBSftpCommon.Unit.fmCreate | SBSftpCommon.Unit.fmWrite, null);
client.Write(handle, 0, GetFileAsBytes(FileToSend));

private byte[] GetFileAsBytes(string FileToSend)
    byte[] fileInBytes;
    using (FileStream inputFile = new FileStream(FileToSend, FileMode.Open))
        using (StreamReader sr = new StreamReader(inputFile, new ASCIIEncoding()))
            fileInBytes = System.Text.ASCIIEncoding.ASCII.GetBytes(sr.ReadToEnd());
    return fileInBytes;

Posted: 03/17/2008 02:01:45
by Ken Ivanov (Team)

StreamReader class is the reason. We strictly recommend to avoid using StreamReader as it may corrupt binary data. Please use the following code to read the file and check if this solves the issue:
private byte[] GetFileAsBytes(string FileToSend)
    byte[] fileInBytes;
    FileStream inputFile = new FileStream(FileToSend, FileMode.Open);
        fileInBytes = new byte[inputFile.Length];
        inputFile.Read(fileInBytes, 0, fileInBytes.Length);
    return fileInBytes;
Posted: 03/17/2008 08:09:45
by Justin Bourlier (Standard support level)
Joined: 02/29/2008
Posts: 2

I did a test using both the function you pasted, as well as the function I pasted, and the results were the same. Before the file goes out, each line ends with a carriage return and a line feed (HEX: 0D 0A). However, once the file gets on the server, there is an extra carriage return added to each line (so it ends with hex: 0D 0D 0A). Unfortunately, the client isn't capable of parsing it with this minor modification. When I test just sending the file using Cute FTP, the file goes in properly (just ending with 0D 0A).

I've found one hack to get this to come out properly, but I don't like the idea one bit. If I remove all instances of the carriage return (0D), so that each new line ONLY ends with a line feed, then the file gets saved with the line ending with carriage return, line feed (0D 0A), which is the proper format.

This seems like an aweful lot of work, shouldn't just setting the property ASCIIMode = true solve all of these issues for me?
Posted: 03/17/2008 08:38:58
by Ken Ivanov (Team)

It seems to be a problem not of SBB but of the server who incorrectly translates EOL characters.

I have one question then: if you need the file to be uploaded unchanged (with CR-LF EOL characters preserved), why do you use ASCII mode? Simply turn it off and you will get the file uploaded with original line endings.



Topic viewed 4201 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!