[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1OcEL8-00DP7W-V3@intern.SerNet.DE>
Date: Fri, 23 Jul 2010 11:14:53 +0200
From: Björn Jacke <bj@...Net.DE>
To: Ted Ts'o <tytso@....edu>, tridge@...ba.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jeremy Allison <jra@...ba.org>, linux-cifs@...r.kernel.org,
linux-nfs@...r.kernel.org, Volker.Lendecke@...net.de,
samba-technical@...ts.samba.org, linux-kernel@...r.kernel.org,
Jan Engelhardt <jengelh@...ozas.de>,
David Howells <dhowells@...hat.com>, 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 2010-07-22 at 21:21 -0400 Ted Ts'o sent off:
> Well, not POSIX, because POSIX doesn't have CreationTime at all.
> BSD's birthtime doesn't allow it to be set, and the question here is
> largely philosophical.
actually, it can (partly :). But the way it can be done is an insane hack:
<quote "http://ace.delos.com/kirk/">
To provide a sensible birth time for applications that are unaware of the birth
time attribute, we changed the semantics of the "utimes" system call so that if
the birth time was newer than the value of the modification time that it was
setting, it sets the birth time to the same time as the modification time. An
application that is aware of the birth time attribute can set both the birth
time and the modification time by doing two calls to "utimes". First it calls
"utimes" with a modification time equal to the saved birth time, then it calls
"utimes" a second time with a modification time equal to the (presumably newer)
saved modification time.
</quote>
Thus it can also be only be set more in the past.
Cheers
Björn
--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
--
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