28 File timestamps

Standard POSIX files have three timestamps: the access timestamp (atime) of the last read, the modification timestamp (mtime) of the last write, and the status change timestamp (ctime) of the last change to the file’s meta-information. Some file systems support a fourth time: the birth timestamp (birthtime) of when the file was created; by definition, birthtime never changes.

One common example of a ctime change is when the permissions of a file change. Changing the permissions doesn’t access the file, so atime doesn’t change, nor does it modify the file, so the mtime doesn’t change. Yet, something about the file itself has changed, and this must be noted somewhere. This is the job of the ctime field. This is necessary, so that, for example, a backup program can make a fresh copy of the file, including the new permissions value. Another operation that modifies a file’s ctime without affecting the others is renaming.

Naively, a file’s atime, mtime, and ctime are set to the current time whenever you read, write, or change the attributes of the file respectively, and searching a directory counts as reading it. A file’s atime and mtime can also be set directly, via the touch command (see touch: Change file timestamps). In practice, though, timestamps are not updated quite that way.

For efficiency reasons, many systems are lazy about updating atimes: when a program accesses a file, they may delay updating the file’s atime, or may not update the file’s atime if the file has been accessed recently, or may not update the atime at all. Similar laziness, though typically not quite so extreme, applies to mtimes and ctimes.

Some systems emulate timestamps instead of supporting them directly, and these emulations may disagree with the naive interpretation. For example, a system may fake an atime or ctime by using the mtime.

The determination of what time is “current” depends on the platform. Platforms with network file systems often use different clocks for the operating system and for file systems; because updates typically uses file systems’ clocks by default, clock skew can cause the resulting file timestamps to appear to be in a program’s “future” or “past”.

When the system updates a file timestamp to a desired time t (which is either the current time, or a time specified via the touch command), there are several reasons the file’s timestamp may be set to a value that differs from t. First, t may have a higher resolution than supported. Second, a file system may use different resolutions for different types of times. Third, file timestamps may use a different resolution than operating system timestamps. Fourth, the operating system primitives used to update timestamps may employ yet a different resolution. For example, in theory a file system might use 10-microsecond resolution for access timestamp and 100-nanosecond resolution for modification timestamp, and the operating system might use nanosecond resolution for the current time and microsecond resolution for the primitive that touch uses to set a file’s timestamp to an arbitrary value.