A symbolic link (or symlink) is a special file that usually has a pathname as its data. When the symbolic link is named in an I/O request—by open(), for example—the link portion of the pathname is replaced by the link's "data" and the path is reevaluated.
Symbolic links are a flexible means of pathname indirection and are often used to provide multiple paths to a single file. Unlike hard links, symbolic links can cross filesystems and can also link to directories. You can use the ln utility to create a symlink.
In the following example, the directories /net/node1/usr/fred and /net/node2/usr/barney are linked even though they reside on different filesystems—they're even on different nodes (see the following diagram). You can't do this using hard links, but you can with a symbolic link, as follows:
ln -s /net/node2/usr/barney /net/node1/usr/fred
Note how the symbolic link and the target directory need not share the same name. In most cases, you use a symbolic link for linking one directory to another directory. However, you can also use symbolic links for files, as in this example:
ln -s /net/node1/usr/src/game.c /net/node1/usr/eric/src/sample.c
Several functions operate directly on the symbolic link. For these functions, the replacement of the symbolic element of the pathname with its target is not performed. These functions include unlink() (which removes the symbolic link), lstat(), and readlink().
Since symbolic links can point to directories, incorrect configurations can result in problems, such as circular directory links. To recover from circular references, the system imposes a limit on the number of hops; this limit is defined as SYMLOOP_MAX in the <limits.h> include file.
You can get some surprising results, depending on how you set up the symbolic links in your system. For example:
# ln -sP /dev/shmem /some_dir # echo > /some_dir/my_file # ln -sP /some_dir/my_file /some_dir/my_link # ls /some_dir my_file my_link # cd /some_dir # ls my_file
Note that ls shows the link if given an explicit path, but otherwise doesn't. Understandably this can cause some confusion and distress. Since it's common for /tmp to be a link to /dev/shmem, this situation can easily arise for special files created in /tmp.
The root of the problem is that when you use chdir() or the shell's cd command to go to some_dir, you actually end up at /dev/shmem, because of the some_dir symbolic link. But you asked the path manager to create a link under /some_dir, not under /dev/shmem, and the path manager doesn't care that /some_dir is a link somewhere else.
The problem can occur any time a directory symlink exists, where the following special files are created by postfixing the symlink path:
We recommend that you always create such links/attachment points by using a canonical path prefix that doesn't contain symlinks. If you do this, then the name will be accessible through the canonical path as well as through the symlink.