From dev-return-12361-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Wed Jul 14 22:09:11 2004 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 97204 invoked from network); 14 Jul 2004 22:09:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 14 Jul 2004 22:09:10 -0000 Received: (qmail 19095 invoked by uid 500); 14 Jul 2004 22:09:10 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 18815 invoked by uid 500); 14 Jul 2004 22:09:08 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 18802 invoked by uid 99); 14 Jul 2004 22:09:08 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Date: Wed, 14 Jul 2004 15:09:02 -0700 From: Noah Misch To: "William A. Rowe, Jr." Cc: dev@apr.apache.org Subject: Re: [PATCH APR 1.0] crtime v.s. intime Message-ID: <20040714220902.GA24768@orchestra.cs.caltech.edu> Mail-Followup-To: "William A. Rowe, Jr." , 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> <20040714214641.GA23692@orchestra.cs.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040714214641.GA23692@orchestra.cs.caltech.edu> User-Agent: Mutt/1.5.6i X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Wed, Jul 14, 2004 at 02:46:41PM -0700, Noah Misch wrote: > > 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 > 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. Well, there is such an OS discreetly marketed as "FreeBSD". Let's implement your proposal so we can populate both fields there. Other BSDs supporting UFS2 may also expose st_birthtime.