From mboxrd@z Thu Jan 1 00:00:00 1970 From: jim owens Subject: Re: ext4 - getting at birth time (file create time) and getting/setting nanosecond time stamps and utime Date: Tue, 20 Oct 2009 17:10:08 -0400 Message-ID: <4ADE2730.4070509@hp.com> References: <524f69650910191017j7883ed7bvdb0329d1a73f34e4@mail.gmail.com> <524f69650910191245t2eb7ffb2r770a7373ec2ba1e3@mail.gmail.com> <5715838A-4568-4273-B1C1-983B348580B6@sun.com> <524f69650910191524k5c9d766fu430c4f7b17d86952@mail.gmail.com> <890110E9-FA69-4356-9BEB-925F98487C52@sun.com> <4ADDB09D.5000707@hp.com> <6E5D19DA-64C5-4A44-9DF4-BEF2AA8DD8AB@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Steve French , linux-fsdevel , samba-technical To: Andreas Dilger Return-path: Received: from g5t0008.atlanta.hp.com ([15.192.0.45]:10039 "EHLO g5t0008.atlanta.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752014AbZJTVKG (ORCPT ); Tue, 20 Oct 2009 17:10:06 -0400 In-Reply-To: <6E5D19DA-64C5-4A44-9DF4-BEF2AA8DD8AB@sun.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Andreas Dilger wrote: > On 20-Oct-09, at 06:44, jim owens wrote: >> Restricting the modification of create time is pointless. > > You contradict yourself later. What we have NOW is creation timestamps > inside on-disk metadata structures the filesystem does not expose. > Going a step further - to expose this in a read-only manner does not > remove the usefulness of this field, but making it read-write does. The apparent contradiction is that I forgot to explicitly say there are two kinds of create time stamps in filesystems: - "user create time" - "internal filesystem create time" My assumption was we were *adding* a "user create time" which must be settable by things like star that archive and restore. Otherwise we have "modification time" before "user create time" when a user restores their files. An "internal filesystem create time" that is not exposed or is read-only is different. And AFAIK most linux filesystems do not have either create time today so unless we want to say Samba only uses ext4, we need to think broader in scope. > Since no Unix tools or applications depend on the presence of this > field, I would say that the default be to NOT allow this timestamp > to be changed. If nobody uses the field, what is the need to protect it? Seems you are now contradicting yourself. jim