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

Dec 6, 2012 at 10: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.

Coordinator
Dec 6, 2012 at 10: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.

Coordinator
Dec 6, 2012 at 10: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.

Coordinator
Dec 6, 2012 at 10: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 1:05 AM
Edited Dec 9, 2012 at 1: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.

Thanks.

Coordinator
Dec 9, 2012 at 2: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 kernel.org'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 12:01 PM

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

Thansk.

Dec 10, 2012 at 12: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());

#endif

Coordinator
Dec 10, 2012 at 12: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.