curl-library
Re: CURLOPT_RESUME_FROM problem (fwd)
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: http://haxx.se/curl.html
- TEXT/PLAIN attachment: ftp-upload.patch