Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
    
Maybe the problem is related to cat, did you examine it with touch? – Mahdi a Mar 22 at 9:24
up vote 8 down vote accepted

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.

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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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