On Wed, 25 Jun 2008, Satish Mittal wrote:

> I am using libcurl 7.1.5.1 easy interface

I think you mean 7.15.1. Released in December 2005. Meaning you should
upgrade.

> It is working fine in case of normal download/upload, but there seems to be
> an issue in upload case if the connection breaks. I get data to be uploaded
> filled in my buffers in-memory from other app threads, and I am copying
> these data buffers inside curl writecallback. To achieve resiliency, I have
> set CURLOPT_RESUME_FROM as -1, so that libcurl resumes appending data at the
> end of remote file. However it seems that in case of a new connection (when
> this CURLOPT_RESUME_FROM option is set) libcurl first calculates the SIZE
> command to calculate the actual size of remote file, and then goes into a
> loop ignoring that much data from my local buffers, before it starts
> appending data. Is this understanding correct?

That's a correct understanding of the old/legacy way of dealing with resumed
FTP uploads, yes. Modern libcurl versions have better ways to deal with that.

> This would mean that I would have to cache all the data I have written
> previously so that I could then pass it all over again to handle resume
> cases.

Or just hand libcurl N bytes of junk since it will discard that part anyway.

> Is there a way I could know the size of the remote file in the resume phase,
> so that I could deterministically know whether my cache can replay the data
> correctly or not. If not, that would at least help me to fail the
> application correctly.

The only sane fix is to upgrade to a newer libcurl and use the SEEKFUNCTION
callback.

But other than that, sure you can read the received headers and parse them to
figure out the SIZE response.

-- 
  / daniel.haxx.se