coreutils: File timestamps

1 
1 28 File timestamps
1 ******************
1 
1 Standard POSIX files have three timestamps: the access timestamp (atime)
1 of the last read, the modification timestamp (mtime) of the last write,
1 and the status change timestamp (ctime) of the last change to the file’s
1 meta-information.  Some file systems support a fourth time: the birth
1 timestamp (birthtime) of when the file was created; by definition,
1 birthtime never changes.
1 
1    One common example of a ctime change is when the permissions of a
1 file change.  Changing the permissions doesn’t access the file, so atime
1 doesn’t change, nor does it modify the file, so the mtime doesn’t
1 change.  Yet, something about the file itself has changed, and this must
1 be noted somewhere.  This is the job of the ctime field.  This is
1 necessary, so that, for example, a backup program can make a fresh copy
1 of the file, including the new permissions value.  Another operation
1 that modifies a file’s ctime without affecting the others is renaming.
1 
1    Naively, a file’s atime, mtime, and ctime are set to the current time
1 whenever you read, write, or change the attributes of the file
1 respectively, and searching a directory counts as reading it.  A file’s
11 atime and mtime can also be set directly, via the ‘touch’ command (⇒
 touch invocation).  In practice, though, timestamps are not updated
1 quite that way.
1 
1    For efficiency reasons, many systems are lazy about updating atimes:
1 when a program accesses a file, they may delay updating the file’s
1 atime, or may not update the file’s atime if the file has been accessed
1 recently, or may not update the atime at all.  Similar laziness, though
1 typically not quite so extreme, applies to mtimes and ctimes.
1 
1    Some systems emulate timestamps instead of supporting them directly,
1 and these emulations may disagree with the naive interpretation.  For
1 example, a system may fake an atime or ctime by using the mtime.
1 
1    The determination of what time is “current” depends on the platform.
1 Platforms with network file systems often use different clocks for the
1 operating system and for file systems; because updates typically uses
1 file systems’ clocks by default, clock skew can cause the resulting file
1 timestamps to appear to be in a program’s “future” or “past”.
1 
1    When the system updates a file timestamp to a desired time T (which
1 is either the current time, or a time specified via the ‘touch’
1 command), there are several reasons the file’s timestamp may be set to a
1 value that differs from T.  First, T may have a higher resolution than
1 supported.  Second, a file system may use different resolutions for
1 different types of times.  Third, file timestamps may use a different
1 resolution than operating system timestamps.  Fourth, the operating
1 system primitives used to update timestamps may employ yet a different
1 resolution.  For example, in theory a file system might use
1 10-microsecond resolution for access timestamp and 100-nanosecond
1 resolution for modification timestamp, and the operating system might
1 use nanosecond resolution for the current time and microsecond
1 resolution for the primitive that ‘touch’ uses to set a file’s timestamp
1 to an arbitrary value.
1