Re: Question regarding FTPS with libcurl CURLOPT_RESUME_FROM option
Date: Wed, 25 Jun 2008 11:34:56 +0200 (CEST)
On Wed, 25 Jun 2008, Satish Mittal wrote:
> I am using libcurl 184.108.40.206 easy interface
I think you mean 7.15.1. Released in December 2005. Meaning you should
> 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
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
But other than that, sure you can read the received headers and parse them to
figure out the SIZE response.
-- / daniel.haxx.seReceived on 2008-06-25