File: coreutils.info,  Node: File timestamps,  Next: Date input formats,  Prev: File permissions,  Up: Top

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 (*note
touch invocation::).  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.