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?
Note:
stat -c %W <filename>
Returns 0 in my system (fedora 22).
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.
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.
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!) – Mar 27 '16 at 00:12