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

[Camille Gonnet]

2016-06-13 23:29 GMT+02:00 Lukasz Marek <lukasz.m.luki2 at gmail.com>:

> On 02.06.2016 14:29, 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.
>>
>> ---
>>   libavformat/ftp.c | 14 ++++++++++----
>>   1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavformat/ftp.c b/libavformat/ftp.c
>> index 0663b47..00747bb 100644
>> --- a/libavformat/ftp.c
>> +++ b/libavformat/ftp.c
>> @@ -220,15 +220,21 @@ static int ftp_send_command(FTPContext *s, const
>> char
>> *command,
>>
>>   static void ftp_close_data_connection(FTPContext *s)
>>   {
>> -    ffurl_closep(&s->conn_data);
>> +static const int close_codes[] = {225, 226, 0};
>> +
>> +    if (s->conn_data) {
>> +        ffurl_closep(&s->conn_data);
>> +        // Need to wait for status, or file transfer might be aborted on
>> server side
>> +        ftp_status(s, NULL, close_codes);
>> +    }
>>       s->position = 0;
>>       s->state = DISCONNECTED;
>>   }
>>
>
> This is not working. ./ffplay ftp://user:pass@localhost/1.avi hangs at
> startup. It was working for you because (probably) your writing operation
> didn't perform seeking (did you enabled ftp-write-seekable?).
> During seek operation, when seek is really done, ftp_abort is called and
> there is ftp_close_data_connection called with status check followed. So
> status is checked twice while sent by server just once.
>
> I can work it out, but just tell what server has this issue. Perfectly
> setup some account for me. You can of course work it out yourself, but
> please test also other scenarios and other servers.
>
> First thing to check is to revert patch completely and replace
> ftp_close_both_connections by ftp_abort inside ftp_close function.
>
>
You are right and I am sorry: I did not make enough tests.

I do not have much information on the server used, this is a ISP one, not
announced in banner. rstatus replies "211 http://www.pureftpd.org/", so
looks like Pure-FTP, which is known to have some issues (logged in
ftp_connect_control_connection). But may be those issues are related to the
data connection closing.

Maybe it should be worked out another way: when any command answers a 1yz
code, we know we should wait for another code, as stated in §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.)

(This explains also why some server does not answers to abort while data
connection is opened)


Unfortunately I have no time to go deeper, so do whatever you want with my
suggestions.
I just wanted to help a little and I am sorry not to be able to go further,
but another day, perhaps.



> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>