Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <479E125E.4050506@rowe-clan.net>
Date: Mon, 28 Jan 2008 11:35:26 -0600
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: [PATCH] for bug 20832. Add double stat option
References: <C3C353B8.A60A1%Brian.Akins@turner.com>
In-Reply-To: <C3C353B8.A60A1%Brian.Akins@turner.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Akins, Brian wrote:
> Against trunk.  Basically, has a new config "EnableDoubleStat" (I know,
> horrible name) off by default.  If on, will use apr_file_info_get on open
> file handle.  Based on patch in thread:
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=43386
> 
> Doesn't apply cleanly against 2.2.8.

AFAICT, this still does not resolve the problem, it simply picks up the
replacement of the file.

It does not address the root 80% of the problem when an open file is
then changed during the transmission.

Doesn't it make more sense to re-fstat at the end of the transmission,
if the expected file sie has again changed, and gracefully finish the
request best-we-can?

I'm strongly -1 on leaving this solution for trunk, but +/- 0 for
backporting this approach to 2.2/2.0 (call it SlowerStatDoubleCheck :-?)
since we can't change fundamentally change the API here.

For trunk, it's time finally to open the file earlier in the request
cycle and use the fstat/file_info_get for the lifetime of the request.
Thoughts?

Bill