apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: RFC: APR_LARGEFILE flag for APR 0.9
Date Thu, 25 Mar 2004 23:49:09 GMT
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.
> 
> +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.)

That's a bad idea, IMHO, because ARP_HAS_LARGE_FILES will still report false. 
You suggest to create a mess, where the library will report one thing but 
behave as another.

e.g. in mod_perl we use the following logic to decide whether mp can support 
large files or not.

I'd rather see:

export CPPFLAGS="-ARP_HAS_LARGE_FILES=1"

or something like that

/* both perl and apr have largefile support enabled */
#if defined(USE_LARGE_FILES) && APR_HAS_LARGE_FILES
#define MP_LARGE_FILES_ENABLED
#endif

/* both perl and apr have largefile support disabled */
#if (!defined(USE_LARGE_FILES)) && !APR_HAS_LARGE_FILES
#define MP_LARGE_FILES_DISABLED
#endif

/* perl largefile support is enabled, apr support is disabled */
#if defined(USE_LARGE_FILES) && !APR_HAS_LARGE_FILES
#define MP_LARGE_FILES_PERL_ONLY
#endif

/* apr largefile support is enabled, perl support is disabled */
#if (!defined(USE_LARGE_FILES)) && APR_HAS_LARGE_FILES
#define MP_LARGE_FILES_APR_ONLY
#endif

/* conflict due to not have either both perl and apr
  * support enabled or both disabled
  */
#if defined(MP_LARGE_FILES_APR_ONLY) || defined(MP_LARGE_FILES_PERL_ONLY)
#define MP_LARGE_FILES_CONFLICT
#endif

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Mime
View raw message