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 > time". 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 development). 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). NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
