2016-06-13 23:29 GMT+02:00 Lukasz Marek <lukasz.m.lu...@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@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
