8

I'm trying to precisely understand when the ctime timestamp of a file is changed. In many places (e.g., in the accepted answer here) it is suggested that any change in the file attributes will also change ctime. However, this seems not to be true, at least on my Ubuntu 12.04 (yes, I know, a bit old...):

cat file.txt > /dev/null

changes the atime, so it changes the file attributes (in the file inode), but does not change the ctime.

Other sources (e.g., here and here) suggest that only some operations on the file attributes actually change the ctime, but a precise list is not provided.

Where may I find a precise reference to which operations change the ctime?

  • Maybe the problem is related to cat, did you examine it with touch? – Mahdi Mar 22 '16 at 9:24
8

There are three time stamps on Unix systems:

  • atime: Access time

    This time stamp tells you when the file was accessed the last time, including only reading access.

  • ctime: Change time

    This time stamp tells you when the file attributes (inode information) changed the last time. That includes e.g ownership and permissions, but a content change also triggers an update of this time stamp.

    Note that changes to the atime seem to be an exception as they do not trigger a ctime update. This is probably because a simple read access which is enough to trigger an atime update does not make any relevant changes to the file attributes. And one of the main purposes of ctime is to help backup tools to determine if a file has changed. The atime is an irrelevant information for such tools and updating a backup just to update a changed atime because somebody has read the file would be useless.

    I'm not sure, but some people think this behavior (changes to atime do not update ctime) is only due to the mount options (like relatime) of the underlying file system that caches and delays atime updates in the inode for performance reasons in memory and only applies them to the real inodes on the disk (triggering a ctime update) under certain conditions.
    @kos tried it and apparently even when mounting a FS with the `strictatime``option, the ctime seems to never update if the atime changes.

  • mtime: Modification time

    This time stamp tells you when the file's content was modified the last time.


So a simple read access using cat FILENAME only changes the atime, but not the ctime as no file attribute got modified. The changed atime does not count.

  • That's exactly the point: why the changed atime does not count? Isn't it a file attribute? – VeryHardCoder Mar 22 '16 at 9:53
  • @VeryHardCoder I tried to elaborate my answer in that point and added some explanations. – Byte Commander Mar 22 '16 at 10:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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