From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve French Subject: Re: ext4 - getting at birth time (file create time) and getting/setting nanosecond time stamps and utime Date: Mon, 19 Oct 2009 14:37:02 -0500 Message-ID: <524f69650910191237w1ec3b6efoef1f21d00e737cf4@mail.gmail.com> References: <524f69650910191017j7883ed7bvdb0329d1a73f34e4@mail.gmail.com> <20091019185855.GC15201@samba1> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: Andreas Dilger , linux-fsdevel , samba-technical To: Jeremy Allison Return-path: Received: from mail-px0-f171.google.com ([209.85.216.171]:50922 "EHLO mail-px0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755706AbZJSTg5 (ORCPT ); Mon, 19 Oct 2009 15:36:57 -0400 Received: by pxi1 with SMTP id 1so643255pxi.33 for ; Mon, 19 Oct 2009 12:37:02 -0700 (PDT) In-Reply-To: <20091019185855.GC15201@samba1> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Oct 19, 2009 at 1:58 PM, Jeremy Allison wrote: > On Mon, Oct 19, 2009 at 12:55:29PM -0600, Andreas Dilger wrote: >> >> As for _updating_ create time, isn't that sort of defeating the purpose >> of create time? > > Yes, you would think so, wouldn't you. Unfortunately that's > the way Windows behaves (create time can be updated) so that's > what we have to emulate. If does indeed make no sense (it's > just another timestamp meta-data that can't be used for auditing > at that point). Updating create time does make it harder to use for auditing, but I expect that 20 years ago when this was added someone was thinking about making sure you could preserve all attributes on backup/restore especially for a system restore after disk failure - and end up with the same file metadata as when you started. -- Thanks, Steve