0 Length file transfers

Oct 20, 2012 at 6:43 PM
Edited Oct 20, 2012 at 10:25 PM

Most of the time this code just works.  However, on occasion I am getting a zero length file transfer.  I use lunarpages.  Here is what happens in the log -

Bad --

< STOR PondInfo1.xml

1876/1876 100% 11724/s

1876/1876 100% 11724/s e.complete

> 150 Accepted data connection

> 226 File Sucessfully transferred

 

Good --

< STOR PondInfo1.xml

> 150 Accepted data connection

1876/1876 100% 11724/s

1876/1876 100% 11724/s e.complete

> 226-File Sucessfully transferred

> 226 0.168 Seconds (measured here), 10.91 Kbytes per second

 

So it seems obvious that we need to wait some way for the accepted connection.  Any thoughts on this?

Oct 20, 2012 at 10:09 PM
Edited Oct 20, 2012 at 10:09 PM

This is probably related to my internet connection.  I am guessing that threading related issues caused the above behaviour, as other logs here show it both ways on failure.  Some type of server response checking would be in place here, it seems.

Coordinator
Oct 22, 2012 at 2:08 PM

Yes, you are right that the output is probably related to the output buffer flushing and threads. If you set the flush on write property to true (I forget the exact property name right this minute) you would probably see more consistent output but I guess it's not guaranteed.

As far as error correction goes, there is none beyond what TCP does. Judging from the log snipets you posted above FtpCLient is sending the data. The next step would be to verify the file size against what was uploaded after the transfer is complete. Stream mode data connections don't provide any means to verify data was successfully received at the other end (TCP is supposed to do this). There are some other types of data connections defined in RFC959 such as block that let you do a little more however this project does not support them.

Oct 22, 2012 at 2:11 PM

I am doing the file size checking, and its working fine. 

 

My thought was to check the response similar to the way it is checking the response from a STOR command.  As it stands, it doesn't appear to me to check in any way that the server accepted the file.

Coordinator
Oct 22, 2012 at 2:14 PM

It reads and checks the server response when the data stream is closed. If a 4xx or 5xx response are sent an exception should be thrown.

Oct 22, 2012 at 2:21 PM

OK, perhaps I missed it.  I traced it through to OpenFile, which checks the response in Execute(cmd), but I don't find where it does a ReadResponse post OpenFile in -public void Upload(Stream istream, FtpFile remote, FtpDataType datatype, long rest)

Another thing of note, it seems my server sends a 226 on some file transfer errors.

Coordinator
Oct 22, 2012 at 5:27 PM
Right that is the reply that is sent post transfer that would determine an error, if the socket was closed premature in an upload an attempted write should trigger an exception and as for downloads there is no real way short of we mentioned earlier by checking file sizes.

Sent from my iPhone

On Oct 22, 2012, at 8:21 AM, Friesen <notifications@codeplex.com> wrote:

From: Friesen

OK, perhaps I missed it. I traced it through to OpenFile, which checks the response in Execute(cmd), but I don't find where it does a ReadResponse post OpenFile in -public void Upload(Stream istream, FtpFile remote, FtpDataType datatype, long rest)

Another thing of note, it seems my server sends a 226 on some file transfer errors.