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: <20100728111525.355a2bd3@notabene>
Date:	Wed, 28 Jul 2010 11:15:25 +1000
From:	Neil Brown <neilb@...e.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jan Engelhardt <jengelh@...ozas.de>,
	Jeremy Allison <jra@...ba.org>, Volker.Lendecke@...net.de,
	David Howells <dhowells@...hat.com>,
	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-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 02/18] xstat: Add a pair of system calls to make
 extended  file stats available [ver #6]

On Thu, 22 Jul 2010 10:24:17 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> Of people can just use xattrs and do it all entirely in user space. I
> assume that's what samba does now, even outside of birthtime.

Much as I despise xattrs, this would definitely be my preference.

ctime and mtime have real cache-coherence semantics which require them being
updated by the kernel (whether the cache is on an NFS client, in a backup
archive, or in a .o translation of a .c file).

create-time, on the other hand, would never be updated by the kernel, and
might sometimes be updated by an application.  So it is a very different sort
of attribute, much like a hypothetical 'last archived' time.

The only role the kernel might have would be setting the 'creation time' when
the file was created, but it seems even that isn't always what is wanted,
because people don't so much what the time of create of the
container-on-disk, but the time of creation of the data-content.

I would want to see a pretty convincing use-case that cannot be solved with
xattrs before 'creation time' was added to a generic kernel interface.

So just use xattrs and don't involve the kernel in any detailed knowledge of
this value.

Maybe xstat should take a list of xattrs to be retrieved as well??  or maybe
not.


But I hope the xstat debate doesn't get bogged down about whether 'create
time' is sensible or not.  Quite apart from the ability to return more
attributes,  I think it has real value is being able to return fewer
attributes, and being allowed to ask for 'best guess' values.  Being able to
do an 'fstat' and being certain that you won't be blocked by a non-responsive
NFS server would be a GOOD THING (TM).

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