What's the difference between modification date and inode's modification date?

Question

I've just found some interesting information for me in man stat:

a, m, c, B
The time file was last accessed or modified, of when the inode was last changed, or the birth time of the inode.

But what's the difference between file last modified time and the inode's modified time? I'm writing a bakup-bash script which allows to copy only last modificated files from two almost equally directories so I need to know which value I will prefer to use :)

Solution

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.

Comments

[Sparhawk]

Is that the same as this question?

[Stéphane Chazelas]

Note however that the access time upon file acccess would change with the mtime changing.