apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: RFC: APR_LARGEFILE flag for APR 0.9
Date Sat, 20 Mar 2004 12:53:48 GMT
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.

+1

[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?

Having APR always use long file offsets when interacting with the app and for 
non-LFS builds doing the ugly conversion (and possibly generating the EFBIG) 
when interacting with the OS seems to be a way to make everything work without 
APR binary compatibility issues.  I'm not suggesting that is the way to go, but 
unless there is some sort of solution it seems that we have an equivalent need 
for APR_LARGEFILE flag with APR 1.0.

(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.)

Mime
View raw message