On Thu, 20 Apr 2006, Daniel Stenberg wrote

>Subject: Re: End of Line Handling (affects ALL platforms)
>Date: Thu, 20 Apr 2006 01:30:09 +0200 (CEST)
>
>On Wed, 19 Apr 2006, David McCreedy wrote:
>
>As far as I remember and the current code looks like, we just don't do any
>size comparisons when doing ASCII transfers. I did it that way since I
>couldn't come up with a reliable way to do that check.
>
>>A real concern here is that Curl closes the connection if the (greater
>>than zero) SIZE doesn't match the number of bytes FTPed. That would be
>>almost all text/ascii transfers. Not a desirable outcome.
>
>It doesn't. The outcome is instead that libcurl can't verify that the
>complete and expected file size was transfered.

I'm a bit confused here; Where am I going wrong?
I'm looking at the code in lib/ftp.c's Curl_ftp_done function.
It sets conn->bits.close to true if the returned SIZE (if there is one)
doesn't match the received byte count:

     if((-1 != conn->size) && (conn->size != *ftp->bytecountp) &&
       (conn->maxdownload != *ftp->bytecountp)) {
      failf(data, "Received only partial file: %" FORMAT_OFF_T " bytes",
            *ftp->bytecountp);
      conn->bits.close = TRUE; /* close this connection since we don't
                                  know what state this error leaves us in */
      return CURLE_PARTIAL_FILE;
    }

That is then checked by url.c's Curl_done function and the connection is
closed if the bits.close flag is on:
     if(data->set.reuse_forbid || conn->bits.close) {
       CURLcode res2;
       res2 = Curl_disconnect(conn); /* close the connection */
       ...

I've confirmed this path: My connection is indeed being closed due to the
conn->bits.close flag being on due to a size mismatch.

-David
Received on 2006-04-21