Classic Shell Scripting - Arnold Robbins [244]
The modification time is changed when the file blocks are altered, but not when the metadata (filename, user, group, link count, or permissions) are changed.
The touch command, or the utime( ) system call, can be used to change file access and modification times, but not the inode-change time. Recent GNU versions of touch provide an option to specify the time as that of a particular file. The ls -l command shows the modification time, but with the -c option displays the inode-change time, and with the -u option, the access time.
These timestamps are not optimal. The inode-change time serves two quite distinct purposes which should have been recorded separately. Consequently, it is impossible to tell when a file first came into existence in a Unix filesystem.
The access time is updated when the file is read with a read( ) system call, but might not be when the file is mapped into memory with mmap( ) and read that way.
The modification time is somewhat more reliable, but the file-copy command normally resets the output-file modification time to the current time, even though its contents were not changed; this is usually undesirable. For this reason, the copy command, cp, has a -p option for preserving file-modification times.
There is no time of last backup recorded: this means that the backup system must retain auxiliary data to track names of files that have been modified since the last incremental dump.
* * *
Tip
Filesystem backup software is carefully written to preserve the timestamps of the files that it reads: otherwise, all files would appear to be newly read after every backup. Systems that use archive utilities, like tar, for backup update the inode-change time by necessity, making that timestamp effectively useless for other purposes.
* * *
For some purposes, one would like to have separate timestamps for read, write, renaming, change of metadata, and so on, but those distinctions are not possible in Unix.
File Links
Despite the considerable utility of the hard and soft (symbolic) filesystem links that we discussed earlier in this Appendix in Section B.4.3, they have been criticized on the grounds that multiple names for the same thing serve only to confuse users, since links create connections between previously isolated branches of the file tree. Moving a subtree that contains soft links can break those links, producing a filesystem inconsistency that did not exist before the move. Figure B-4 shows how a soft link can be broken by a move, and Figure B-5 shows how such a link can be preserved, depending on whether relative or absolute paths are used in the links.
Figure B-4. Breaking relative symbolic links with moves
Figure B-5. Moves can preserve absolute symbolic links
There are several other problems with both hard and soft links:
When a linked file is updated, either by replacement with a file-copy command or by a program, such as a text editor, is a hard link preserved? It depends on how the update is done. If the existing file is opened for output and rewritten, its inode number remains unchanged, and hard links are preserved. However, a system crash, or a disk-full error, during the update might result in the loss of the entire file. A cautious programmer might therefore write the new version under a temporary name, and only when the copy was safely completed would he remove the original (thus decrementing its link count by one) and rename the copy. The renaming operation is comparatively fast, so the window for failure is much smaller. The replacement file will have a new inode number and a link count of one, breaking hard links.
We tested several text editors, and found that all seemed to use the first approach, preserving hard links. The emacs editor allows a choice of either behavior.[24] In contrast, if you edit or rewrite a file that is a soft link, then you are modifying the original data, and as long as its pathname remains unchanged, all other soft links that point to