Classic Shell Scripting - Arnold Robbins [245]
For hard links, the two update methods can also result in the new file having a different owner and group: update-in-place preserves owner and group, whereas copy-and-rename sets them to values for the user who performed that action. Thus, the behavior of the two kinds of links is often inconsistent after file modification.
Consider symbolic links for directories: if you have a symbolic link from subdir to /home/jones/somedir, then that link will almost certainly be broken when you move the file tree to another filesystem where /home/jones/somedir does not exist.
It is generally better to use relative paths in the link, and then only to directories at the same level, or below: a symbolic link from subdir to ../anotherdir is preserved if a file tree beginning at least one directory higher in the tree is moved. Otherwise, the link is broken.
Broken symbolic links are not diagnosed at the time of the break, but are only discovered later when such a link is referenced: it may then be too late to do anything about the break. This is the same problem with personal address books: your friends can move without informing you, breaking your link to them. The find command can be used to find broken links, as shown in Chapter 10.
Symbolic links to directories pose a problem for relative directory changes as well: changing to the parent directory of a symbolic link moves to the parent directory of the pointed-to directory, rather than to the parent of the link itself.
Symbolic links are a problem when file archives are created: sometimes the links should be preserved, and other times, the archive should simply include a copy of the file itself in place of the link.
File Size and Timestamp Variations
The inode entry for each file includes its size in bytes, which can be zero if the file is empty. The long form of ls output displays the size in the fifth column:
$ ls -l /bin/ksh
List verbose file information
-rwxr-xr-x 1 root root 172316 2001-06-24 21:12 /bin/ksh
GNU versions of ls provide the -S option to sort the listing by descending file size:
$ ls -lS /bin | head -n 8
Show the 8 largest, in order of descending size
total 7120
-rwxr-xr-x 1 rpm rpm 1737960 2002-02-15 08:31 rpm
-rwxr-xr-x 1 root root 519964 2001-07-09 06:56 bash
-rwxr-xr-x 1 root root 472492 2001-06-24 20:08 ash.static
-rwxr-xr-x 2 root root 404604 2001-07-30 12:46 zsh
-rwxr-xr-x 2 root root 404604 2001-07-30 12:46 zsh-4.0.2
-rwxr-xr-x 1 root root 387820 2002-01-28 04:10 vi
-rwxr-xr-x 1 root root 288604 2001-06-24 21:45 tcsh
The -S option can be handy when you fill up a filesystem and you want to find which files are possible culprits. Of course, if your ls lacks that option, just use ls -l files | sort -k5nr to get the same result.
* * *
Tip
If you suspect that a currently running process has filled up the filesystem, on Sun Solaris you can find big open files like this (as root, if you want to see more than your own files):
* * *
# ls -lS /proc/*/fd/*
List all open files-rw------- 1 jones jones 111679057 Jan 29 17:23 /proc/2965/fd/4
-r--r--r-- 1 smith smith 946643 Dec 2 03:25 /proc/15993/fd/16
-r--r--r-- 1 smith smith 835284 Dec 2 03:32 /proc/15993/fd/9
...
* * *
Note
In this example, killing process 2965 might remove that large file, but at least you know that jones is involved.
GNU/Linux has a similar /proc facility, but alas, the Solaris solution doesn't work because the reported file sizes on GNU/Linux are incorrect.
* * *
The disk-free command, df, reports the current disk usage, or with the -i option, the inode usage. The disk-usage command, du, can report the total space used for the contents of individual directories, or with the -s option, a compact summary. Examples are given in Chapter 10. The find command with the -mtime and -size options can find files that have been created recently, or are unusually large: see Chapter 10.
The -s option to ls shows an additional leading column that gives the file size in blocks:
$ ls -lgs /lib/lib* | head