Message-ID: <c5df85930703260610i24ff9bb2i13a8d11ce63a6071@mail.gmail.com>
Date: Mon, 26 Mar 2007 14:10:23 +0100
From: "James Youngman" <jay@gnu.org>
To: "Eric Blake" <ebb9@byu.net>
Subject: Re: Support for st_birthtime
Cc: "bug-findutils mailing list" <bug-findutils@gnu.org>, cygwin@cygwin.com
In-Reply-To: <4607BCA0.1060406@byu.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4607BCA0.1060406@byu.net>
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On 3/26/07, Eric Blake <ebb9@byu.net> wrote:
> Corinna only replied to the cygwin list.  It looks like Windows will
> populate st_birthtime with st_ctime when reading filesystems that don't
> support birthtime.  This is a bit yucky, as it adds to the problem wrongly
> being perpetuated by Microsoft that ctime stands for creation time instead
> of change time.

Worse, it makes it impossible to ask questions like "was this file
changed since it was created?" and expect reliable answers.      On
systems which have no "birth time" you get the answer "no" when the
correct answer is "we don't know".

> But I guess all findutils can do is go by what stat()
> reports, and users must be aware that ctime==btime may be the indicator
> that btime is not supported for that file.

But I don't think we can do that, because it is indistinguishable from
the "file never changed" case.

James

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/