Hi,

> > Rob Lievaart suggested a scenario where a command
> connection request may be
> > getting to the server before the data connection
> upload/closure sequence
> > completes.

I don't regularly read this list, so I probably missed some
messages, but since I saw my name so I thought I'd respond.

The scenario that is referred to was that the user of the
libcurl library incorrectly set the CURLOPT_INFILESIZE
using a 64 bit value. Al worked well upto 2Gb, then
problems happened. The upload seemed to go OK, but then
when libcurl finished the upload it looked like after the
filetransfer libcurl detected that the number of bytes
transferred did not match the number specified
through CURLOPT_INFILESIZE (because it was a 64 bit value)
And closed the command connection.

When that happened, the connection close reached the server
before the last bytes of the file on the dataconnection, and
the IIS server decided (correctly) to remove the entire file
because the command connection disappeared.

NOTE: Since this was someone elses application I did not have
the sources, so this analysis is based on tcpdump, strace
and objdump. For me it explained the behavior, and if I used
a hex editor to remove the call to
curl_easy_setopt CURLOPT_INFILESIZE everything worked OK.
I don't know if libcurl closed the command connection or
if the application itsself caused that in repsonse to the
transfer error. The application in question does not log
a lot :-(

Other FTP servers seem to treat closing the command connection
differently and there they did not have any problems.

So in this case it was/is user error as far as I can tell.

I don't know if this is also the case in your case. But I thought
I'd explain the scenario that was referred to. In my case
the 2 gigabyte boundary was very exact, 1 byte below 2Gb and all
was well, one byte above and it failed. If this is the case, then
it is easy to fix by replacing the call to
curl_easy_setopt CURLOPT_INFILESIZE with CURLOPT_INFILESIZE_LARGE,
or removing it completely since it is optional for FTP.

I hope this information helps, one way or another.

Kind regards,

Rob Lievaart
Received on 2007-12-06