The functions stat() and fstat() return the following times associated with a file:
Unix implementations vary somewhat as to which functions update these times. In most implementations, the same basic set of functions cause a time associated with a file to be updated. For example, a read() of a file updates st_atime and a write() to a file updates both st_mtime and st_ctime. For a write, the file status, i.e., the file size, may change. However, some implementations have functions which update these times that other implementations do not have. For example, System V has a lockf() function and IEEE 1003.1-1990 does not.
Not only do implementations vary as far as which functions update the times returned by stat(), but implementations also vary in the procedure used to do the update. In some implementations, the times are updated when the function is performed, e.g., when a read() returns, the st_atime of the file has been set to the current time. In other implementations (including IEEE 1003.1-1990), the times returned by stat() are only updated periodically as a performance consideration. For example, when a read() is performed, the st_atime of the file is ``marked for update.'' At some later time, e.g., when a stat() on the file is done, the ``mark for update,'' left as a result of the most recent read(), causes the st_atime of the file to be set to the current time. For implementations which update stat() times in this manner, the values of the times are accurate only within the time period in which the ``marks for update'' are converted into time value changes. For implementations which update stat() times when a function is performed, the stat() times are as accurate as possible.
Most applications do not require accurate stat() times. One of the most common uses of stat() times is make. The make application is successfully used with almost all implementations.
The issue of stat() times becomes somewhat more difficult in a transparent file access environment. A file in a remote file system is physically located on a server. The server maintains its own clock which may or may not be synchronized with the client's clock.
If a client is caching to improve performance, then it is difficult to make accurate times available to processes on other clients. Reads and writes to remote files may actually only involve accessing the local caches. The server must be made aware of these accesses. There are solutions to these problems. The client could send a packet to the server when an access occurs or the server could poll its clients for updates whenever a stat() is done on a file. However, any solution which tries to maintain stat() times as accurately as can be done on a local file system incurs a performance penalty.
A more serious problem is that a server may not be able to maintain some or all of the stat() times because the native file system of the server does not have the equivalent concepts of stat() times. It is not uncommon for a file system to have only a file creation time.