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]
Date:	Mon, 9 Aug 2010 09:07:03 +1000
From:	Neil Brown <neilb@...e.de>
To:	Jeremy Allison <jra@...ba.org>
Cc:	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 Sun, 8 Aug 2010 05:12:09 -0700
Jeremy Allison <jra@...ba.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..
or something).

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
cheaply.
(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
sub-optimal interface.

NeilBrown
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ