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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTinEFFAWMu62j2sCPy=ArExZNm2miJOGoXbG65jC@mail.gmail.com>
Date:	Fri, 6 Aug 2010 21:42:41 -0500
From:	Steve French <smfrench@...il.com>
To:	Neil Brown <neilb@...e.de>
Cc:	Jeremy Allison <jra@...ba.org>, Jeff Layton <jlayton@...hat.com>,
	utz lehmann <lkml123@...4n2c.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Volker.Lendecke@...net.de, David Howells <dhowells@...hat.com>,
	Jan Engelhardt <jengelh@...ozas.de>,
	linux-cifs@...r.kernel.org, linux-nfs@...r.kernel.org,
	samba-technical@...ts.samba.org, linux-kernel@...r.kernel.org,
	viro@...iv.linux.org.uk, linux-fsde@...per.es
Subject: Re: [PATCH 02/18] xstat: Add a pair of system calls to make extended 
	file stats available [ver #6]

On Fri, Aug 6, 2010 at 7:29 PM, Neil Brown <neilb@...e.de> wrote:
> On Fri, 6 Aug 2010 18:58:42 -0500
> Steve French <smfrench@...il.com> wrote:
>
>> On Fri, Aug 6, 2010 at 6:30 PM, Neil Brown <neilb@...e.de> wrote:
>> > On Thu, 5 Aug 2010 22:55:06 -0500
>> > Steve French <smfrench@...il.com> wrote:
>> >
>> >> On Thu, Aug 5, 2010 at 10:38 PM, Neil Brown <neilb@...e.de> wrote:
>> >> > On Thu, 5 Aug 2010 16:52:18 -0700
>> >> > Jeremy Allison <jra@...ba.org> 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).

Perhaps also useful for MacOS (and other BSD), not just Windows,
although MacOS may use cifs more often than nfs.




-- 
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/