Hi;

I am struggling with this a little bit, and it's leading me to a pair of questions, 1 tactical and 1 strategic. :-)

My libcurl calling app has noticed that a local file on the drive in our transfer directory is of a smaller size then the file of the same name that is on the ftp server so it now knows that it should tell curl to resume the file from the appropriate position

  if(iCntRsm)
    curl_easy_setopt(g_pCrl, CURLOPT_RESUME_FROM_LARGE, iCntRsm);

I think this is not the complete solution to the problem, because the callback pointed to by CURLOPT_WRITEFUNCTION does not know that we now want it to append to the file instead of (over)writing the file from new, so i need to modify the call to fopen in the callback to reflect this:

     psFtpDat->pFd = fopen(psFtpDat->pcInfFil, iAppend ? "a":"w");

So this leads to the tactical question:

I am pretty sure that I now need to either create a global variable called g_iAppend that i will use to inform the callback or i need to add another field to the structure that get's passed to the callback by way of CURLOPT_WRITEDATA:

 curl_easy_setopt(g_pCrl, CURLOPT_WRITEDATA, &sFtpDat);

 struct FtpDat
 {
   const char *pcInfFil;
   FILE *pFd;
   int iAppend;
 };

I prefer hacking the struct to adding a global, but i am worried that libcurl might be expecting the WRITEDATA struct to be of fixed size and this would not be the same size as the stuff in all of the examples.

Am I ok with doing this?

The process of thought that led to this tactical solution led to the following The strategic question:

libcurl knows that the app just told it to resume, so why cant the callback ask libcurl about this?

The tactical solution that i have come up with means that the application has to say the same thing twice (once to libcurl and once to the callback) and that is 'A Bad Thing' in my tiny little mind because if you have to say things twice, there is a chance to get the two 'sayings' in an inconsistent state.

I notice that there is no curl_getopt() API and I assume that there was an explicit design choice involved in omitting that API and it's probably a well thought out and defensible one.

Having said that, it still seems not unreasonable for the callbacks to have access to a 'curl context' as part of the goodies that libcurl passes it.

Does such a thing exist and i have just not found it?

Or am i fundamentally misunderstanding something?

thank you all so much in advance for any comments or analysis or explanation you make make. :-)

johnu

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-11-05