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

[Jeff Layton]

On Sun, 8 Aug 2010 05:12:09 -0700
Jeremy Allison <jra at samba.org> wrote:

> On Fri, Aug 06, 2010 at 01:38:36PM +1000, Neil Brown wrote:
> > I'm curious.  Why do you particularly care what interface the kernel uses to
> > provide you with access to this attribute?
> 
> It's a matter of taste. The *BSD's have this right IMHO. It
> should be part of the stat information. A file timestamp is not
> an EA. Making it available that way just feels like an appalingly
> tasteless kludge. It offends the artist in me :-).
> 

It would be more convenient if this were part of stat() but adding a
new stat call is non-trivial. Even if we did that, it still doesn't
solve the problem of being able to set the create time. The fact that
that's rarely done doesn't really matter much -- we ought to shoot for
the semantics that are needed to handle this properly.

If we do settle on a xstat() interface, it might also end up being able
to report things like selinux labels which are also available and
settable via xattr. I don't see a problem with presenting the same data
via multiple interfaces. If presenting this data via xattr solves the
immediate problem of being able to properly store and report the create
time then it seems like a win.

> > 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?
> 
> It is *already* useful to us, and is widely used in
> existing code. The occasions when btime is set are
> relatively rare, and at that point we store it in a
> separate EA for Windows reporting purposes.
> 

If that's the case, don't you have to query for this EA every time you
need to return the create time anyway? If so, then doing this really
isn't any more costly -- you'd just be querying a different EA, right?

-- 
Jeff Layton <jlayton at redhat.com>