[FFmpeg-devel] [PATCH] FTP graceful close data connection to avoid server abort

[Camille Gonnet]

2016-06-09 1:19 GMT+02:00 Lukasz Marek <lukasz.m.luki2 at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>