20

This is slightly tricky.

I am uploading files to FTP asynchronously. After uploading each file I am checking the status of the upload operation for that file. This can be done with StatusCode property of the FtpWebResponse object for that request. The code snippet is as give below.

FileStream fs = File.Open(fileName, FileMode.Open);

while ((iWork = fs.Read(buf, 0, buf.Length)) > 0)
    requestStream.Write(buf, 0, iWork);

requestStream.Close();

FtpWebResponse wrRet = ((FtpWebResponse)state.Request.GetResponse());

There are about 37 StatusCode values as per msdn. I am unaware as to which of these status code values will assure that the file is uploaded successfully. Some of them I used in my code to check for success are :

wrRet.StatusCode == FtpStatusCode.CommandOK 
wrRet.StatusCode == FtpStatusCode.ClosingData
wrRet.StatusCode == FtpStatusCode.ClosingControl
wrRet.StatusCode == FtpStatusCode.ConnectionClosed
wrRet.StatusCode == FtpStatusCode.FileActionOK
wrRet.StatusCode == FtpStatusCode.FileStatus

But I am unaware of the rest. I need to be sure about these codes because based on the failure or success of the upload operation I have other dependent operations to be carried out. A wrong condition can affect the remaining code. Another thought that crossed my mind was to simply put the above code into a try..catch and not depend on these status codes. With this I would not be depending on the status codes and assuming that any failure will always be directed to the catch block. Kindly let me know if this is the right way.

abatishchev
  • 98,240
  • 88
  • 296
  • 433
Nishant
  • 905
  • 1
  • 16
  • 36
  • I had my troubles with FTP servers. I would go with a pragmatic solution and simply check if the file just uploaded to the server can be found again after upload. I know it's not answering the question - but I just came to the conclusion that I could not trust the FTP servers response – MacGyver Oct 12 '17 at 21:33

1 Answers1

6

FtpStatusCode.ConnectionClosed is 426 which is Connection closed; transfer aborted so I would think that would be a failure actually. Anything in the 2XX range should generally be a success. For the FTP clients that I've built the one that I only remember receiving for successful upload is 226 - FtpStatusCode.ClosingData

Chris Haas
  • 53,986
  • 12
  • 141
  • 274
  • Thanks Chris. But as I have stated above I have also checked for ClosingData value. Most of the times or almost always in my development environment I get this status. But somehow in the production environment I am getting an issue. (I am uploading the file again if the status codes donot match any of them as mentioned in my above post. The file is actually getting uploaded twice.) There is some other status code retrieved which is not one among the one's as I mentioned above, but still is a case of success. Any ideas on this? – Nishant Jan 17 '11 at 14:43
  • 1
    I'd recommend turning on tracing for System.Net and seeing if you can get more information as to why the upload is failing. http://blogs.msdn.com/b/dgorti/archive/2005/09/18/471003.aspx – Chris Haas Jan 17 '11 at 15:06
  • @Nishant There exists many different status codes due to different version of FTP RFC but you have to be sure which version of FTP you are using and then you should use unambiguous FTP codes better use SFTP or FTPS. – AZ_ Oct 13 '17 at 07:52
  • @Nishant also if you are using NAT with Active FTP it's not going to work. http://slacksite.com/other/ftp.html – AZ_ Oct 13 '17 at 07:59
  • @ChrisHaas To clarify, are you suggesting `bool success = (int)response.StatusCode >= 200 && (int)response.StatusCode < 300;`? – RMart Jan 25 '18 at 16:23
  • To be honest, this was from 7 years ago and I really don't remember too much anymore. I would say that if you ever build an FTP client you should always test it with every possible server that you'll be communicating with because they all have their own quirks, especially ones that have been around for a while. One command can also generate several responses which is why the `1xx` range exists so those need to be watched for. But generally speaking, if `226` is in the list of command received I think you can assume a success. – Chris Haas Jan 25 '18 at 17:57