[PATCH 02/18] xstat: Add a pair of system calls to make extended file stats available [ver #6]
neilb at suse.de
Sun Aug 8 17:07:03 MDT 2010
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 :-).
Unfortunately whenever you work on a collaborative project someone has to make
concessions to taste, as we all taste different.. (or have different taste..
So I think it is very important to clearly differentiate the practical issues
from the aesthetic issues as I think we can hope for unity on the former, but
never on the latter.
> > 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.
I'm probably sounding like a scratched record, but when you say "is widely
used" do you mean "is used in samba which is widely used" or do you mean "is
used in a wide variety of applications"?
Because if you are only saying the former, then I don't think we should copy
BSD, but rather I think we should provide exactly the semantics that are most
useful to samba - and that would seem to be creation-time and DOS flags which
the filesystem can store directly in the inode and which samba can access
(and I would prefer to use xattrs, but that is a taste thing and as I'm not
writing the code, I don't get to choose the taste).
But if you are saying the later, then sharing those details might help us see
that copying bsd is actually the best thing to do, or maybe that something
else is better.
I'm just afraid that if some new interface is added without clear,
comprehensive and up-front justification then we will end up getting a
More information about the samba-technical