Access: 2014-05-20 11:04:27.012146373 -0700
Modify: 2014-04-05 20:59:32.000000000 -0700
Change: 2014-05-20 11:04:22.405479507 -0700
Access: last time the contents of the file were examined.
Modify: Last time the contents of the file were changed.
Change: Last time the file's inode was changed.
The change time includes things like modifying the permissions and ownership, while the modify time refers specifically to the files contents.
Or more precisely (from
man 2 stat):
The field st_atime is changed by file accesses, for example, by execve(2), mknod(2), pipe(2), utime(2) and read(2) (of more than zero bytes). Other
routines, like mmap(2), may or may not update st_atime.
The field st_mtime is changed by file modifications, for example, by mknod(2), truncate(2), utime(2) and write(2) (of more than zero bytes). More‐
over, st_mtime of a directory is changed by the creation or deletion of files in that directory. The st_mtime field is not changed for changes in
owner, group, hard link count, or mode.
The field st_ctime is changed by writing or by setting inode information (i.e., owner, group, link count, mode, etc.).
Interestingly, direct manipulation of the file times counts as modification of the inode, which will bump the ctime to the current clock time. So you can set the ctime to the current time, but you can't set it to any other time, as you can the other two. This makes the ctime a useful canary to spot when the file's mtime might have been moved back.
Also, while you can change the inode without changing the file contents (that is, the ctime can change without the mtime changing), the reverse is not true. Every time you modify the contents of the file you will necessarily also end up bumping the ctime.