[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=JvwrwpmteFcXW1f5s95+_w_iCT+04Sy7bbTtR@mail.gmail.com>
Date: Mon, 2 Aug 2010 10:09:49 -0400
From: Greg Freemyer <greg.freemyer@...il.com>
To: Jeff Layton <jlayton@...hat.com>
Cc: Neil Brown <neilb@...e.de>, David Howells <dhowells@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jan Engelhardt <jengelh@...ozas.de>,
Jeremy Allison <jra@...ba.org>, Volker.Lendecke@...net.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-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]
> Furthermore, I'll go ahead and propose the following (simple) semantics:
>
> 1) birthtime is initialized to the current time when a new inode is
> created
>
> 2) it's settable via the xattr to an arbitrary value
>
> Either way, the xattr for this ought to be named the same on all
> filesystems. Samba shouldn't need to know or care what the underlying
> filesystem is, as long as it presents the correct xattr.
>
> That should make samba happy, and be reasonably simple to implement.
Is there any reason to allow birthtime to be set in advance of the
current birthtime?
ie restore / copy tools clearly need to backdate it, but I'd prefer to
see it not advance-able.
Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists