On Tue, 9 Dec 2003, Dave Meyer wrote:

> Quick preface: I see that Rob Braun has submitted a patch or two for trying
> to deal with files larger than 2 GB with http. Sadly, I did not see that
> until *after* I fiddled around with ftp support for the same on my own.
> Perhaps I can look at a later patch that moves my stuff to conform more to
> what he has already done...

I lost contact with Rob Braun so his patch remains unapplied due to some
glitches. We could probably continue this work based on your patch. I have
some comments on it, that I would like to see modified before I apply it. I'm
grateful for your effort, and I really do want large-file support added to
libcurl. I've missed it!

> This patch adds large file support for ftp transactions in particular,
> although it probably messes around a little bit with how transactions in
> other protocols occur. This solution relies on the use of the off_t data
> type, meaning that it gives large file support on supporting platforms by
> setting using -D_FILE_OFFSET_BITS=64 or an equivalent thereof.

This is all goodness. From what I understand, off_t is the POSIX way to
support >32 bits file sizes.

> Note that I've also included support for specifying resume offsets which are
> larger than 2 GB, which means that the Curl_setopt function has changed the
> sizes of some of its arguments from long to off_t. I've attempted to update
> the documentation for the relevant option keys in addition to changing the
> keys themselves.

Here's where I would like to chime in! I would rather have new options that
set sizes that use a type different from 'long', to prevent a lot of
applications to break when updating to this new version. The old (current)
ones, would be deprecated and recommended not to be used anymore, but since we
read the option arguments from the stack using va_arg(), we can't just start
reading off_t for applications that pass in longs...

This isn't such a big job, since this only concerns four options:

 CURLOPT_RESUME_FROM
 CURLOPT_INFILESIZE
 CURLOPT_MAXFILESIZE
 CURLOPT_PROGRESSFUNCTION (the new version of this would take a function
   pointer to a function that accepts off_t arguments for the sizes).

Perhaps appending "_BIG" is fine? Or "_NEW"?

I would also like to see the 'off_t' handling get its own CURLOPTTYPE in the
curl.h file (similar to how CURLOPTTYPE_OBJECTPOINT is used etc) so that it
can be initialized like the rest in the option list in the header as well as
parsed nicer in url.c:Curl_setopt().

Or am I missing something?

> Finally, several of the places that once used atoi or strtol to scan text
> for numbers have been replaced with calls to strtoll (or a new function
> called str2offset which mimics the behavior of str2num, but with off_t's
> rather than longs). This allows numbers larger than 2 GB to actually be
> read properly out of the strings in which they appear.

We also need to check for the strtoll() function in the configure script for
this. (I'll add that check right now)

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click