On Sat, Mar 20, 2004 at 07:53:48AM -0500, Jeff Trawick wrote:
> Joe Orton wrote:
> >APR 0.9.x can't change the size of apr_off_t, but it's still useful to
> >be able to use O_LARGEFILE in a few specific cases on LFS platforms when
> >the application knows it is safe: to allow writing >2Gb log files in
> >particular. It's not safe to use in general, since {f,l,}stat() will
> >fail on a >2gb file with a 32-bit off_t, so needs to come with a big
> >warning sign.
>
> So for any file where the app will only open it or append to it, it can
> safely specify APR_LARGEFILE and the right thing will happen, with big
> "log" files where possible.
Yup, read()s from it will work too... even sendfile() might...
> [In the hope that this isn't really needed for 1.0]
> With APR 1.0, what is the reason for not having the same flag? Isn't there
> still the same situation where APR 1.0 will usually be built without large
> file support, and a random user can't rebuild APR with LFS without breaking
> existing apps, but may still want to support large "log" files?
I'm working on 1.0 changes to enable LFS support by defining apr_off_t
as off64_t and hence making O_LARGEFILE the default, so I was thinking
APR_LARGEFILE could be either undefined or a nullop in 1.0, either way
works.
The tricky things for 1.0 are when/if to enable apr_off_t==off64_t and
the ABI impact of that decision, and dealing with sendfile support.
> (Related trivia: Maybe README.dev needs notes on large file support,
> starting with the basic Unix requirement you outlined in a PR yesterday
>
> export CPPFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
> ./configure
>
> and then having folks add comments on platforms where it has been tested
> and/or where there are special considerations.)
Good idea, thanks.
joe
