Download Fails On Some Servers After 'REST 0' Sent

Question

The FTPConnection.DownloadFile() method is failing on my PROD FTP server but not TEST server. After rerteiving a list of files and then choosing to download one the PROD server appears to choke on the 'REST 0' command that is automatically sent by the FTP library. The prod server responds with a 550, the TEST server issues a 500 after the 'REST 0' is sent. I'm not sure if the client library can recover from the 500 and not 550 or the PROD server is just says no more.

I'm also guessing that even if the server does not support REST, nor the client library as I have read, a 'REST 0' prior to the RETR when using DownloadFile() is standard FTP protocol. I have posted log below TEST server looks exactly the same up to the 550 response, where it issued a 500.

I am unable to find any docs on turning off the 'REST 0' command sent prior to download. I am only a user of the FTP servers but I could offer up suggestions to resolve. Anyone offer any suggestions, I am using the free edition of the library?


DEBUG [FTPConnection] 4 Oct 2012 10:28:45.690 : DownloadFile(C:\SFTP Data\REI\CardOrders\REIGCINC3_20121004094748.json,REIGCINC3_20121004094748.json)
DEBUG [FTPControlSocket] 4 Oct 2012 10:28:45.722 : ---> REST 0
DEBUG [FTPControlSocket] 4 Oct 2012 10:28:45.769 : 550 Operation is not supported under Connect:Enterprise FTP server.
INFO [FTPControlSocket] 4 Oct 2012 10:28:45.769 : Expected reply codes = [350] (strict=False)
DEBUG [FTPClient] 4 Oct 2012 10:28:45.800 : REST failed which is ok (Operation is not supported under Connect:Enterprise FTP server. (code=550))
DEBUG [FTPControlSocket] 4 Oct 2012 10:28:45.909 : Setting socket timeout=500
ERROR [FTPControlSocket] 4 Oct 2012 10:28:47.003 : Read failed ('' read so far)

Answer 1

Can you please email support at enterprisedt dot com a full log file at the Debug level?

Answer 2

Done

Answer 3

It seems that Connect:Enterprise can't cope with the REST command, and it somehow messes up the transfer.

Still not sure what the best solution is here. It's a pretty basic FTP command.

Answer 4

We have a legacy app that I based a new application on and it uses V 1.0.1956.18548 of the .NET FTP library. This app currently works against said prodcution server, just for kicks I'm going to try to use it and see what happens.

I hate to use a '50' year old library that I don't even see docs for.

I also talked to the connect:Enterprise fols last evening and they did say that their TEST server is a couple of revisions newer than the PROD system, so, at least going forward they may have this resolved.

Why is a 'REST 0' sent prior to a RETR when calling DownloadFile()? ...no way to turn this off I guess?

Answer 5

We've had a good look at this and I think we can remove the REST 0. We'll send you a new DLL.

Answer 6

This issue was boiled down to a misunderstanding, on my part, of the exception thrown by the library. The problem was the