[PATCH 02/18] xstat: Add a pair of system calls to make extended file stats available [ver #6]

Ted Ts'o tytso at mit.edu
Thu Jul 22 19:21:30 MDT 2010

On Fri, Jul 23, 2010 at 11:03:47AM +1000, tridge at samba.org wrote:
> The other big difference from POSIX timestamps is that the
> CreationTime is settable on Windows, and some of the windows UI
> behaviour relies on this.

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.  Does it literally mean "file creation time" in
terms of when the OS created the file, or does it mean "file" in the
sense of application contents.  For example, if an application edits
the file and saves it out using "write file to foo.new; sync; rename
foo to foo.bak; rename foo.new to foo", should the creation time for
the newly written file "foo" be the time when the editor saved out the
file (i.e., when "foo.new" was created), or copied from the original
file "foo"'s creation time.

This is something (whether or not the application is allowed to set
the creation time) that I think makes sense to be either a filesystem
level mount option, or superblock tunable, or even a per-process
personality flag.

However, I think Linus's idea of using a per-process flag to control
whether or not "ctime" has the original POSIX semantics or some new
"creation time" semantics would lead to a huge amount of confusion.
Given that a number of new filesystems, including both ext4 and btrfs,
have creation time, it makes sense for us to have a fourth timestamp.
Whether or not our creation time is settable or not is a separate
question, and I don't think we need to follow BSD's lead on this.  If
GNOME and/or KDE applications start using it, I could see this
becoming that gets wide adoption fairly quickly.

						- Ted

More information about the samba-technical mailing list