Putting files with non Ascii filenames

Question

I was wondering what the status is on the bug reported 1 year ago:
http://www.enterprisedt.com/forums/viewtopic.php?t=397
http://www.enterprisedt.com/forums/viewtopic.php?t=330

It was stated that it might be added to new versions, but the bug still exists in 1.2.2.

EnterpriseDT.Net.Ftp.FTPControlSocket.InitStreams() still contains:

            writer = new StreamWriter(stream, Encoding.GetEncoding("US-ASCII"));
            reader = new StreamReader(stream, Encoding.GetEncoding("US-ASCII"));

When trying to put files with filenames containing non-ascii characters a exception is thrown:
ERROR [EnterpriseDT.Net.Ftp.FTPClient] 7 mar 2006 14:47:50.963 : Caught exception : Unable to write data to the transport connection: An established connection was aborted by the software in your host machine.
at System.Net.Sockets.NetworkStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.IO.BinaryWriter.Write(Byte[] buffer, Int32 index, Int32 count)
at EnterpriseDT.Net.Ftp.FTPClient.PutBinary(Stream srcStream, String remoteFile, Boolean append)
A first chance exception of type 'System.IO.IOException' occurred in edtftpnet-1.2.2.dll

i.e. putting

Answer 1

It hasn't been high priority for us as we've been quite busy, but we'd like to get it fixed. The only solution right now is to fix it yourself - but if you contribute a patch that'll make it a lot easier for us to add it to the next release (which is quite soon).

Is the only solution right now to fix it and recompile it myself or is there a workaround?

Thanks

Answer 2

When commands are sent thru the FTPControlSocket that contains file and directory names with non-ASCII characters, these characters are changed to something else and therfore causing errors. In my case, the connection to the FTP server was shut down.

This is because the StreamWriter and StreamReader uses the US-ASCII encoding, FTPControlSocket.cs on line 287-288:

            writer = new StreamWriter(stream, Encoding.GetEncoding("US-ASCII"));
            reader = new StreamReader(stream, Encoding.GetEncoding("US-ASCII"));

In order to fix the problem, and be able to send non-ascii characters in the control stream a different encoding has to be used.

When testing I found that Encoding.UTF8, Encoding.Unicode will not work. But "Windows-1252" will work.

So the lines above (FTPControlSocket.cs:287-288) has to be changed to:

                  writer = new StreamWriter(stream, Encoding.GetEncoding(1252));
                  reader = new StreamReader(stream, Encoding.GetEncoding(1252));

This will allow ASCII characters plus the most common Western European characters to pass thru, i.e. it will widen the set of allowed characters. See http://en.wikipedia.org/wiki/Windows-1252.

BUT, it will still not allow all filenames. For example the file name "عكתּ.txt" cannot be used.
(Generating non ASCII-filenames can be made thru the "Character Map" application found on the Start menu.)

So, the fix is better than using the US-ASCII encoding, but not enough. Since the FTP RFC only states that NVT-ASCII should be supported it might be hard to find a encoding that works with all servers. The best would be to let the user change the encoding on the FTPClient object, defaulting to US-ASCII.

Answer 3

Hi All,
I am also getting this same error. But it automatically gets resolved and doesn't throw the error again. It happens sometimes. I don't have any non-ascii file name issue. It simply throws this error (Unable to write data to the transport connection) and then if we try again after sometime, it processes the same file without raising any error. It happens very rarely. But I am wondering why it is happening...

Can anyone please help me understand this?

Thanks.

Lita

Answer 4

This error will happen if you are transferring a lot of files at once. Every transfer consumes a TCP connection, which are finite resources. It takes up to 4 minutes to free up connections, so transferring lots of small files can result in "Unable to write data to the transport connection". The cure is to sleep for a few seconds in between transfers, or when this error occurs (or increase the number of connections available).

Answer 5

Thanks Bruce for your quick response.

Regards,

Lita