From dev-return-14279-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Wed Jun 01 15:18:51 2005 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 4040 invoked from network); 1 Jun 2005 15:18:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 Jun 2005 15:18:51 -0000 Received: (qmail 7300 invoked by uid 500); 1 Jun 2005 15:18:47 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 7241 invoked by uid 500); 1 Jun 2005 15:18:46 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 7215 invoked by uid 99); 1 Jun 2005 15:18:46 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of jorton@redhat.com designates 66.187.233.31 as permitted sender) Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 01 Jun 2005 08:18:44 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j51FIZt5015416 for ; Wed, 1 Jun 2005 11:18:35 -0400 Received: from radish.cambridge.redhat.com (radish.cambridge.redhat.com [172.16.18.90]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j51FIYO06439 for ; Wed, 1 Jun 2005 11:18:34 -0400 Received: from radish.cambridge.redhat.com (localhost.localdomain [127.0.0.1]) by radish.cambridge.redhat.com (8.13.1/8.12.7) with ESMTP id j51FIXAB015210 for ; Wed, 1 Jun 2005 16:18:33 +0100 Received: (from jorton@localhost) by radish.cambridge.redhat.com (8.13.1/8.12.10/Submit) id j51FIXC3015209 for dev@apr.apache.org; Wed, 1 Jun 2005 16:18:33 +0100 Date: Wed, 1 Jun 2005 16:18:33 +0100 From: Joe Orton To: dev@apr.apache.org Subject: Re: #34708: truncated files vs FILE buckets Message-ID: <20050601151833.GA13865@redhat.com> Mail-Followup-To: dev@apr.apache.org References: <20050601141502.27DF3198@ajax.apache.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20050601141502.27DF3198@ajax.apache.org> User-Agent: Mutt/1.4.1i X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 though. > 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. joe