Use In a
Unix-like OS, the
ln shell command can create either a hard link (via the
API function ) or a symbolic link (via the symlink() function). The command's syntax for creating a symbolic link is as follows: ln -s "" "" Ideally, the target should exist, although a symbolic link may be created to a non-existent target. The following example creates an empty file called "foo", then creates a symbolic link called "bar" that points to "foo". $ touch foo $ ln -s foo bar Most operations treat a link as an alias for the target. For example, shell commands that access file content access the content of the target file. But file management operations may operate on the link or the target. The lstat(), lchown() and readlink() APIs apply directly to the link file, not their targets. An app (e.g.,
ls or
find) can use lstat() rather than
stat() to distinguish and report on symbolic links instead of their targets. Because the rename() and
unlink() API functions are coded to operate on symbolic links, the
rm and
mv commands (which use these APIs) affect the symbolic link itself. The
cp command has options that allow either the symbolic link or the target to be copied. The ls -l command can reveal a symbolic link's target. The output shows the link's name, followed by a -> mark and the link's target. In this example, ls reveals the symbolic link that the previous example created. $ ls -l bar lrwxrwxrwx 1 user group 3 Aug 4 18:40 bar -> foo
Storage Early implementations stored the link path in a regular file. The file contained the target path as text, and the file mode bits marked the file as a symbolic link. The reported size of such a symbolic link is the number of characters in the path it points to. The
file system permissions of a symbolic link are not used; the access modes of the target file are controlled by the target file's own permissions. (
FreeBSD,
NetBSD,
DragonFly BSD, and
macOS can modify file permissions and
file attributes of a symbolic link, through lchmod() and lchflags() APIs respectively.) To enhance storage space and performance, the
fast symlink allowed storage of the target path within the
data structures used for storing file information on disk (
inodes). This space stores a list of disk
block addresses allocated to a file. Thus, symbolic links with short target paths are accessed quickly. Systems with fast symlinks often fall back to using the original method if the target path exceeds the available inode space. The original style was
retroactively termed a
slow symlink. It is also used for disk compatibility with other or older versions of operating systems. Although storing the link value inside the inode saves a disk block and a disk read, the operating system still needs to parse the path name in the link, which always requires reading additional inodes and generally requires reading other, and potentially many, directories, processing both the list of files and the inodes of each of them until it finds a match with the link's path components. Only when a link points to a file in the same directory do "fast symlinks" provide significantly better performance than other symbolic links.
Other uses Dangling symlinks are intentionally created by
systemd as key-value data storage when the value is small enough. The symlink name is the key, the target path is the value. The rationale is that, instead of 2 system calls for read and 3 system calls for write, it would only take 1 system call to read and 2 system calls for write. ==Windows==