Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 14 Jul 2004 14:46:41 -0700
From: Noah Misch <noah@cs.caltech.edu>
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Cc: dev@apr.apache.org
Subject: Re: [PATCH APR 1.0] crtime v.s. intime
Message-ID: <20040714214641.GA23692@orchestra.cs.caltech.edu>
Mail-Followup-To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>,
	dev@apr.apache.org
References: <6.1.0.6.2.20040702150359.03171ad0@pop3.rowe-clan.net>
 <6.1.2.0.2.20040714150323.02cbaa80@pop3.rowe-clan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6.1.2.0.2.20040714150323.02cbaa80@pop3.rowe-clan.net>
User-Agent: Mutt/1.5.6i

On Wed, Jul 14, 2004 at 03:21:33PM -0500, William A. Rowe, Jr. wrote:
> Ping list - 12 days elapsed.  No interest?  Only comment was from Branko, 
> and not in response to this patch.
> 
> Since we've floated about this for a year with only a few interested parties
> - I suppose it's time to kill the proposal and just document the inconsistency.
> 
> Attached are two patches, one introduces intime/crtime (I missed adding 
> the actual apr_time_t intime member in the last patch - this fixes it.)
> The doc_fix patch just documents the deficiency.  Let's pick one or the other.
> 
> Bill

Splitting ctime does improve representational correctness, but as I think about
it, I doubt it helps folks write more portable programs.  It does not presently
make more information available; each OS either fills intime or fills crtime.
Library users will need to modify their code to cope with this change, albeit
trivially, and I'm not seeing what they will then have the new ability to do.

For better or worse, ctime just isn't very useful.  On Windows, it lets you
smile about the fact that you have your very own file from 1988.  On Unix, it's
a (weak) auditing tool; one can change a file's mtime to anything, but doing so
advances ctime, and one cannot arbitrarily set ctime.  As such, assuming the
integrity of the kernel and the filesystem backing store, a file will not have
changed since the later of its ctime or mtime.

It might be useful to define e.g. APR_CTIME_IS_CREATE_TIME on systems where that
is the case.  This would not prompt changes to programs that use ctime casually,
and programs that do care could test for that and behave accordingly.

I would (unofficially, of course) vote for the comments patch.  Should APR ever
support an OS that makes both crtime and intime available, I think your change
would be excellent.  If such an OS is mainstream now and we just don't support
it yet, then your proposal may be good to incorporate so APR can support both
values later without such an API change.

Hopefully that is of some value to the discussion.