Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762218Ab0HFX6q (ORCPT ); Fri, 6 Aug 2010 19:58:46 -0400 Received: from mail-pw0-f46.google.com ([209.85.160.46]:59396 "EHLO mail-pw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760423Ab0HFX6n convert rfc822-to-8bit (ORCPT ); Fri, 6 Aug 2010 19:58:43 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KE5cKbuItURgtfJiYSnX6pWW67du36HNZCWDlDCz7o/mb7QutkFgEWUTkX73vQoxab bzouPRtM6e6UdW5F2aKGHjiRj9wtkbemerVYBYSafR9XkeObpe2i0OUg+BCiAOjyS6go Nt+iHn7jTJHhFSq1xXNfDiARt/2L48Fbsy9RQ= MIME-Version: 1.0 In-Reply-To: <20100807093057.7683bedd@notabene> References: <20100715021709.5544.64506.stgit@warthog.procyon.org.uk> <20100715021712.5544.44845.stgit@warthog.procyon.org.uk> <30448.1279800887@redhat.com> <1280524978.2452.9.camel@segv.aura.of.mankind> <20100801092529.5e6ba0e0@corrin.poochiereds.net> <20100805235218.GB31233@jeremy-laptop> <20100806133836.49757af9@notabene> <20100807093057.7683bedd@notabene> Date: Fri, 6 Aug 2010 18:58:42 -0500 Message-ID: Subject: Re: [PATCH 02/18] xstat: Add a pair of system calls to make extended file stats available [ver #6] From: Steve French To: Neil Brown Cc: Jeremy Allison , Jeff Layton , utz lehmann , Linus Torvalds , Volker.Lendecke@sernet.de, David Howells , Jan Engelhardt , linux-cifs@vger.kernel.org, linux-nfs@vger.kernel.org, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, linux-fsde@jasper.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3567 Lines: 74 On Fri, Aug 6, 2010 at 6:30 PM, Neil Brown wrote: > On Thu, 5 Aug 2010 22:55:06 -0500 > Steve French wrote: > >> On Thu, Aug 5, 2010 at 10:38 PM, Neil Brown wrote: >> > On Thu, 5 Aug 2010 16:52:18 -0700 >> > Jeremy Allison wrote: >> >> >> Don't add it as an EA. It's *not* an EA, it's a timestamp. >> > >> > I'm curious. ?Why do you particularly care what interface the kernel uses to >> > provide you with access to this attribute? >> > >> > And given that it is an attribute that is not part of 'POSIX' or "UNIX", it >> > would seem to be an extension - an extended attribute. >> > As the Linux kernel does virtually nothing with this attribute except provide >> > access, it seems to be a very different class of thing to other timestamps. >> > Surely it is simply some storage associated with a file which is capable of >> > storing a timestamp, which can be set or retrieved by an application, and >> > which happens to be initialised to the current time when a file is created. >> > >> > Yes, to you it is a timestamp. ?But to Linux it is a few bytes of >> > user-settable metadata. ?Sounds like an EA to me. >> > >> > Or do you really want something like BSD's 'btime' which as I understand it >> > cannot be set. ?Would that be really useful to you? >> >> Obviously the cifs and SMB2 protocols which ?Samba server support can >> ask the server to set the create time of a file (this is handled >> through xattrs today along with the "dos attribute" flags such as >> archive/hidden/system), but certainly it is much more common (and >> important) to read the creation time of an existing file. >> > > Just a point of clarification - when you say it is common and important to be > able to read the creation time on an existing file, and you still talking in > the context of cifs/smb windows compatibility, or are you talking in the > broader context? > If you are referring to a broader context could be please give more details > because I have not heard any mention of any real value of creation-time out > side of window interoperability - have such a use clearly documented would > assist the conversation I think. > > If on the other hand you are just referring the the windows interoperability > context ... given that you have to read an EA if the create-time has been > changed, you will always have to read and EA so having something else is > pointless ... or I'm missing something. There are other cases, less common than cifs and smb2. One that comes to mind is NFS version 4, but there are a few other cases that I have heard of (backup/archive applications). The RFC recommends that servers return attribute 50 (creation time). See below text: time_create 50 nfstime4 R/W The time of creation of the object. This attribute does not have any relation to the traditional UNIX file attribute "ctime" or "change time". -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/