apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: #34708: truncated files vs FILE buckets
Date Wed, 01 Jun 2005 15:18:33 GMT
On Wed, Jun 01, 2005 at 04:15:02PM +0200, bugzilla@apache.org wrote:
> ------- Additional Comments From trawick@apache.org  2005-06-01 16:15 -------
> I don't have any patches and/or tested code.  I was hoping you'd chime in ;)
> I concur on checking for rv != APR_EOF.
> For core_output_filter, looks like there are two paths, based on what we
> originally found out for the file length (before truncation):
> a) big enough for sendfile
> not improved by file-bucket-read fix; I suspect sendfile caller will loop since
> we won't make any progress when calling sendfile (0 bytes written)
> incidentally, I've seen a few loopers with sendfile enabled on HP-UX; supposedly
> that is NOT due to truncated file but instead something happening in network
> layer; catching this no-progress-made scenario would exit the loop on the HP-UX
> scenario as well

Ah, interesting.  The logic is there to return APR_EOF to the caller for
the "made no progress" case for some of the implementations.  Looks like
the HP-UX, Solaris and possibly AIX implementations are missing it

> b) not big enough for sendfile
> With the file-bucket-read fix we won't be misled by e->length since we do the
> bucket read in the path you mentioned to find the length.  rv will be APR_EOF
> (not abnormal when reading a file) and length will be 0 (not abnormal when
> reading a file).  How do we know that something has gone wrong?  Compare the
> declared length of the file (e->length) with the length returned by
> file-bucket-read?

Hum, good questions.

But: it *is* always an error for a FILE bucket to read() EOF from the
file.  That should never happen, because it must never attempt to read
past the fixed segment of the file it represents.

So maybe it's also correct for file_bucket_read to return APR_EOF if
that's what it read.  I'll have a play around with that.


View raw message