cURL / Mailing Lists / curl-library / Single Mail


Re: CURLOPT_RESUME_FROM problem (fwd)

From: Daniel Stenberg <>
Date: Wed, 28 Nov 2007 22:00:34 +0100 (CET)

On Wed, 28 Nov 2007, nf2 wrote:

> i don't understand why in the function ftp_state_ul_setup() libcurl
> expects that fread_func returns exactly "readthisamountnow" (16384) bytes.
> -----------------------------------------------
> actuallyread = (curl_off_t)
> conn->fread_func(data->state.buffer, 1, (size_t)readthisamountnow,
> conn->fread_in);
> passed += actuallyread;
> if(actuallyread != readthisamountnow) {

That seems like a plain oversight, a bug. What do you say about the attached
patch for this?

> i guess CURLOPT_RESUME_FROM wants me to resend the entire content of the
> file again in one go.

Yes, it is made so that the application passes the same data/file, for both
regular uploads and for resumed uploads.

> unfortunately in curlftpfs i lost this data, because i don't cache it. i
> just want to REST/STOR from the end of the existing file.

Then we need some new magic to tell libcurl about it...

> what i would need is a CURLOPT_RANGE for uploads, but i think CURLOPT_RANGE
> is ignored here.

Yes, we need to introduce code to support this. Feel very welcome to work on
this and post patches here for review!

> i could use CURLOPT_APPEND, but i think REST/STOR would be safer, because it
> probably checks the size of the existing file on the server side...

Safer in what regard? Since you still have to do a specified REST to a certain
point, libcurl has to know that point.

  Commercial curl and libcurl Technical Support:

Received on 2007-11-28