Is there any historic reason? Stat stores last accessed time, last modified time and last changed time , but not the creation time! Isn't that important information.

I can't understand why the developers would leave out such an important piece of information. Some filesystems do store the data, as pointed in this question. But clearly the importance of this information has been downplayed. Why is it so?


stat -c %W <filename>

Returns 0 in my system (fedora 22).

  • @EightBitTony I have made my question more clear. – 0aslam0 Mar 9 '16 at 14:10
  • 1
    I still think it's a duplicate, there is some discussion in the other question. i was going to provide a comment after voting to close as a dupe, but I was interrupted. Even if it's not a duplicate, your question is probably off-topic as a result of being too broad or opinion based. – EightBitTony Mar 9 '16 at 14:24
  • 3
    I'm baffled by this question, entirely about history, being considered a duplicate of a question that doesn't mention history at all. Since I can't post an answer now, I'll have to settle for this comment: the other answers are wrong. Unix originally did have creation time, as you can see in the V1 man page and implementation of maknod - it seems to have been replaced by "inode change time" when the implementation was converted to C (it might even have been an accident!) – user41515 Mar 27 '16 at 0:12
  • 2
    Yeah, this is definitely not a duplicate and should not be marked as such. Like Wumpus Q. Wumbley mentioned, this one is about history and why such a useful piece of information is not available. Not a question about what filesystem includes it. – Clox Feb 10 '18 at 12:07

Modern file systems do store the file object creation time. One reason it wasn't done earlier was probably there was no consensus about what a file creation time should be, i.e. is it when the file object (inode) was created or the file content (data), and what to do when a file is restored from backup.

| improve this answer | |

The historical answer is of course that it originally didn't store the creation time, and nobody felt compelled to add this new feature.

There's a good reason for not storing the creation time, which is that this is a very poorly defined notion. If the system kept track of some time and called it “creation time”, there would be a lot of cases where this would not be a useful time.

Many applications save a file by first writing to a temporary file, and then renaming the file to overwrite the old one. This approach is preferable to overwriting the file in place because if the application or the system crashes while writing the file, this only leaves a temporary file around, whereas the overwrite method leaves a broken file in place. But this approach means that if you define a file's creation time as the date the file was actually created, then most data files would have a creation time that's the same as their modification time, or only a fraction of a second in the past. So the creation time would not provide any information.

This could be changed by requiring the application to somehow declare that the new file is in fact a new version of the old file, and so should inherit its creation time. But that would require a lot of extra complexity, unlike the traditional timestamps (content modification, access, and inode change) which can be updated automatically (on each write, on each read, on each metadata change).

There are other cases where the creation time is debatable. When you copy a file with preserved metadata (cp -p, rsync -a, …), are you creating the copy, or are you copying a file including its creation time? When you restore a file from backup, should the creation time be restored or should it be the time of the restore?

If you want to make the creation time of a file meaningful, enter it under version control. Then you can define the creation time as the time of the first commit that includes the file, and this information will be recorded and preserved.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.