|
|
A symbolic link is a special type of file that represents another file. The data in a symbolic link consists of the pathname of a file or directory to which the symbolic link file is linked. The link that is formed is called symbolic to distinguish it from a regular (also called a hard) link such as can be created by using the ln(1) command. A symbolic link differs functionally from a regular link in three major ways: files from different file systems may be linked together; directories as well as regular files may be symbolically linked by any user; and a symbolic link can be created even if the file it represents does not exist.
In order to understand how a symbolic link works, it is necessary to understand how the UNIX operating system views files. (The following description pertains to files that belong to the standard System V file system type.) The internal representation of a file is contained in an inode, which contains a description of the layout of the file data on disk as well as information about the file, such as the file owner, the access permissions, and the access times. Every file has one inode, but a file may have several names, all of which point to the inode. Each name is called a regular (or hard) link.
When a file is created, an inode is allocated for it, the file contents are stored in data blocks, and an entry is created in a directory. A directory is a file whose data is a sequence of entries, each consisting of an inode number and the name of a file. The inode initially has a link count of one, which means that this file has one name (or one link to it).
We are now in a position to understand the difference between the creation of a regular and a symbolic link. When a user creates a regular link to a file with the ln(1) command, a new directory entry is created containing a new file name and the inode number of an existing file. The link count of the file is incremented.
In contrast, when a user creates a symbolic link both a new directory entry and a new inode are created. A data block is allocated to contain the pathname of the file to which the symbolic link refers. The link count of the referenced file is not incremented.
Symbolic links can be used to solve a variety of common problems. For example, it frequently happens that a disk partition (such as root) runs out of disk space. With symbolic links, an administrator can create a link from a directory on that file system to a directory on another file system. Such a link provides extra disk space and is, in most cases, transparent to both users and programs.
Symbolic links can also help deal with the built-in pathnames that appear in the code of many commands. Changing the pathnames would require changing the programs and recompiling them. With symbolic links, the pathnames can effectively be changed by making the original files symbolic links that point to new files.
In a shared resource environment like NFS, symbolic links can be very useful. For example, if it is important to have a single copy of certain administrative files, symbolic links can be used to help share them. Symbolic links can also be used to share resources selectively. Suppose a system administrator wants to do a remote mount of a directory that contains sharable devices. These devices must be in /dev on the client system, but this system has devices of its own so the administrator does not want to mount the directory onto /dev. Rather than do this, the administrator can mount the directory at a location other than /dev and then use symbolic links in the /dev directory to refer to these remote devices. (This is similar to the problem of built-in pathnames since it is normally assumed that devices reside in the /dev directory.)
Finally, symbolic links can be valuable within the context of the virtual file system (VFS) architecture. With VFS new services, such as higher performance files, events, and network IPC, may be provided on a file system basis. Symbolic links can be used to link these services to home directories or to places that make more sense to the application or user. Thus one might create a database index file in a RAM-based file system type and symbolically link it to the place where the database server expects it and manages it.