This project is read-only.

Issue: FtpDataType.Binary isn't used, corrupts files

Dec 6, 2012 at 11:03 PM

Ddi you see the issue I posted a few days ago? I am using a workaround right now. But I think it's important enough to give it some attention. It doesn't look hard to solve either. 

Issue number: 364


Thanks in advance.

Dec 6, 2012 at 11:19 PM

Just now seeing it, codeplex doesn't email me half the time issues are reported even though I have it set to do so. I will look into and get back with you.

Dec 6, 2012 at 11:40 PM

Please check out the latest revision in which this bug along with other directly related bugs in regards to resumes should be addressed.

Dec 6, 2012 at 11:45 PM

Also, please note that if you do use ASCII transfers don't rely on the file size (Length property of the stream or GetFileSize() method) to be non-zero because some servers (NetBSD's ftpd) won't give a file size unless TYPE = I.

Dec 9, 2012 at 2:05 AM
Edited Dec 9, 2012 at 2:14 AM

Superb reaction, quickly resolved it. I will test it monday morning rightaway.

I do use only the binary mode, together with a method which will always download the whole stream, also when the given size is incorrect. It was my testcase of downloading a binary file that failed on comparison.


Dec 9, 2012 at 3:42 AM

Alright, well we'll see what happens here. I think the only reason this hasn't come up before is because other servers default to TYPE I and's server was defaulting to TYPE A. Anyway, it brought to light several bugs of the same nature so thanks for reporting it. Once the fix is confirmed on your end I'll close the ticket and push a new binary to the download page.

Dec 10, 2012 at 1:01 PM

All tests completed succesfully on the default settings on with the latest commit.


Dec 10, 2012 at 1:13 PM

Just 1 warning on the release build:

FtpClient.cs (743): variable e is declared but is never used


catch (IOException e) {

#if DEBUG                       

System.Diagnostics.Debug.WriteLine("IOException thrown closing control connectin: " + e.ToString());


Dec 10, 2012 at 1:34 PM
Yeah, that's due to one of the SslStream issues that was reported. I haven't done anything with it yet because I haven't gotten an response from the person that reported the issue. It's nothing to be concerned with right now.