2009/5/13 Fred Moore <[email protected]>: > Hi David, > > in you previous post you stated: > >> There's no way to know (at the server side) if the file has been >> transferred correctly. When the data connection is closed, >> the server thinks the file transfer finished correctly >> but this must not be the case. > > This is something of the utmost importance for FTP in general and FTP used > in a business context in particular: can you expand a bit on that?
There are several modes of operation in FTP, of those the only one that is always implemented (while the other ones hardly ever are) is STREAM mode. In this mode, the data is sent as an unstructured stream of bytes carrying no other information such as the "End Of File". So , in this mode, it is considered that a file transfer has been completed when the data connection is closed. But, of course, it is possible that the connection be closed before the file sending has been complete. As an example, you can start uploading a file with Filezilla and then select : Stop and delete all ( I have a localized version, it should say something similar to that). The connection will be closed and then the FTPServer will think the file arrived correctly. If the client renamed the file itself when the upload finished, you'd be sure that it had been successfully written ( Besides, you can use MD5 checks for data integrity). > Is this stemming from a limitation of the FTP wire-format as described in > RFCs (e.g. no reliable file size provided by the client upfront)? > > If so: do you know of FTP clients that "play ball" with the server and > severe the data connection is a way that surfaces as an error on the server > (which can then use this condition as an indication of likely file > truncation)? > > Cheers, > F. >
