X-Spam-Check-By: sourceware.org Message-ID: Date: Mon, 26 Mar 2007 14:10:23 +0100 From: "James Youngman" To: "Eric Blake" Subject: Re: Support for st_birthtime Cc: "bug-findutils mailing list" , cygwin AT cygwin DOT 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 DOT 1060406 AT byu DOT net> X-Google-Sender-Auth: d018e3130717169a Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On 3/26/07, Eric Blake 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/