apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: apr_strfsize cannot handle sizes bigger than a few MiBs without largefiles support
Date Tue, 29 Jan 2002 19:03:32 GMT
From: "Stas Bekman" <stas@stason.org>
Sent: Tuesday, January 29, 2002 12:50 PM

> William A. Rowe, Jr. wrote:
> > From: "Stas Bekman" <stas@stason.org>
> > Sent: Tuesday, January 29, 2002 12:39 PM
> > 
> >>apr_strfsize accepts the size arg as apr_off_t, so unless apache it
> >>built with largefiles support, apr_off_t == long int, which means that
> >>apr_strfsize is unusable for sizes bigger than a few MiBs.
> > 
> > This is correct.  If the platform supports LARGEFILES, then it better
> > danged well say so and own up to the responsibilities of implementing
> > them in APR (seek, etc - all supporting apr_off_t sized jumps).
> > 
> >>I've checked mod_autoindex, and it has this problem too as it uses
> >>apr_off_t for its size and feeds it to apr_strfsize.
> > 
> > That is correct.
> which means that if you build Apache with no LARGEFILES, and you have a 
> "large" file it's your problem.


> So apr_strfsize is not a general purpose functions anymore, since it's 
> tied to files. Which means that we again need to reimplement it, if we 
> want to have a general purpose function for formatting sizes and handle 
> big files without imposing a LARGEFILES requirement.

No, it's an apr function.  But please consider the following;

Can Apache handle the file you've just listed as 24KB instead of 4GB+24KB?

No, of course not.  Nor could any program built with APR.

I'd comprimize, if you like.  If we determine that this .size member 
is > MAX_APR_OFF_T, we set the size to MAX_APR_OFF_T.  In apr_strfsize,
we replace that value MAX_APR_OFF_T with some hardcode, such as "Huge ",
so folks don't go downloading it.

If the filesystem doesn't handle it, I fail to see what benefit we get from
displaying it.

Unless you want to make apr_strfsize into something more generic, such as
apr_format_brief_size_binary(), taking the hugest int we can pass it, and 
returning a binary metric NNNNm where m is a magnitude.  There wouldn't
be any harm in that, someone could extend it to apr_format_brief_size_metric()
for true decimal representations.  But apr_strfsize sure sounds like a 
filesystem API here :)

BTW - the veto of changing the type of the dirent .size member from
apr_off_t still stands.


View raw message