2016-06-09 1:19 GMT+02:00 Lukasz Marek <lukasz.m.lu...@gmail.com>: > On 09.06.2016 00:25, Michael Niedermayer wrote: > > On Thu, Jun 02, 2016 at 02:29:47PM +0200, Camille Gonnet wrote: > >> When writing files to FTP, if the data connection is closed before the > >> control connection, the server may handle it as an aborted file transfer > >> and create and leave the file empty. > > > > which ftp server, or is that in the RFC, if so please refer to it >
This is in RFC959. §4.1.1 (page 26) *An unexpected close* on the control connection will cause the server to take the effective *action of an abort (ABOR)* and a logout (QUIT). §5.2 (page 45): To prevent a race condition here, *the server sends a reply (226) after closing the data connection* (or if the connection is left open, a "file transfer completed" reply (250) and the user-PI should wait for one of these replies before issuing a new transfer command). §5.4 (page 49) Certain commands require a second reply for which *the user should also wait*. These replies may, for example, report on the progress or completion of file transfer or the closing of the data connection. They are secondary replies to file transfer commands. §4.2 (page 37) 1yz Positive Preliminary reply The requested action is being initiated; *expect another reply before proceeding with a new command*. (The user-process sending another command before the completion reply would be in violation of protocol; but server-FTP processes should queue any commands that arrive while a preceding command is in progress.) On a STOR command, we expect a "150 Accepted Data connection". So the 226 or 250 should always been replied, or an error. RFC is good for reference, unfortunately even popular linux > implementations don't follow it strictly (sometimes it is hard to say > they follow at all some aspects). Regarding aborting and stuff it is > really implementation dependent. I can't remember now which > implementation and what version, but one was totally unresponsive on > control connection while active transfer on data connection, so the only > way to abort it was to close data connection. > > > Reverting order of closing should be OK, but I'm not really sure > expecting all implementation to send 225/226 code is correct. I would > suggest to at least check state if it is UPLOADING and apply that change > only for this case. Perfectly this behaviour could be enabled by an > option and autodetected in ftp_connect_control_connection when server > send its name (note 220 code's message may be overwritten so an option > to enforce is needed) > I understand that it may cause some problems depending on implementations, but closing the data connection and the control connection without any check, considering that those are on different ports and can be re-ordered, this will lead to transfer aborted in many situations. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
