Re: [PATCH 02/18] xstat: Add a pair of system calls to makeextended file stats available [ver #6]
From: Neil Brown
Date: Fri Aug 06 2010 - 20:29:24 EST
On Fri, 6 Aug 2010 18:58:42 -0500
Steve French <smfrench@xxxxxxxxx> wrote:
> On Fri, Aug 6, 2010 at 6:30 PM, Neil Brown <neilb@xxxxxxx> wrote:
> > On Thu, 5 Aug 2010 22:55:06 -0500
> > Steve French <smfrench@xxxxxxxxx> wrote:
> >> On Thu, Aug 5, 2010 at 10:38 PM, Neil Brown <neilb@xxxxxxx> wrote:
> >> > On Thu, 5 Aug 2010 16:52:18 -0700
> >> > Jeremy Allison <jra@xxxxxxxxx> 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
I really don't think NFSv4 is a separate justification. I'm fairly sure
that attribute was only including in NFSv4 for enhanced Windows
compatibility (windows interoperation was a big issue during the protocol
That leaves hypothetical "backup/archive applications". Do you have a
concrete example? Or we are left with just various flavours of Windows
compatibility (not that I have a problem with Windows compatibility, but if
that is the only reason that we have creation-time then I think it is
important to be clear and open about that).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/