Re: [PATCH 02/18] xstat: Add a pair of system calls to make extended file stats available [ver #6]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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".



-- 
Thanks,

Steve
--
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


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux