On Fri, Jul 23, 2010 at 11:03:47AM +1000, tridge@xxxxxxxxx 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 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
