apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <...@manyfish.co.uk>
Subject Re: RFC: APR_LARGEFILE flag for APR 0.9
Date Mon, 22 Mar 2004 11:02:18 GMT
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

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
> ./configure
> and then having folks add comments on platforms where it has been tested 
> and/or where there are special considerations.)

Good idea, thanks.


View raw message