Misplaced Pages

Revision as of 22:33, 13 August 2009

Template:Distinguish2 In computing, a symbolic link (also symlink or soft link) is a special type of file that contains a reference to another file or directory in the form of an absolute or relative path and that affects pathname resolution. Symbolic links first appeared in the 4.2BSD release of Berkeley Unix (1983). Today they are supported by the POSIX operating-system standard, most Unix-like operating systems, Windows Vista, and to some degree in Windows 2000 and Windows XP.

Symbolic links operate transparently for most operations: programs which read or write to files named by a symbolic link will behave as if operating directly on the target file. However, programs that need to handle symbolic links specially (e.g., backup utilities) may identify and manipulate them directly.

A symbolic link merely contains a text string that is interpreted and followed by the operating system as a path to another file or directory. It is a file on its own and can exist independently of its target. If a symbolic link is deleted, its target remains unaffected. If the target is moved, renamed or deleted, any symbolic link that used to point to it continues to exist but now points to a non-existing file. Symbolic links pointing to non-existing files are sometimes called orphaned or dangling.

Symbolic links exist in contrast to hard links. Hard links may not normally point to directories and they can not link paths on different volumes. Symbolic links may point to any file or directory irrespective of the volumes on which the source and destination reside.

Some Unix as well as Linux distributions use symbolic links extensively in an effort to reorder the file system hierarchy. This is accomplished with several mechanisms, such as variant and context-dependent symbolic links. This offers the opportunity to create a more intuitive or application-specific directory tree and to reorganize the system without having to redesign the core set of system functions and utilities.

POSIX and Unix-like operating systems

In POSIX-compliant operating systems, symbolic links are created with the symlink() system call. When using the ln shell command, this system call is used, instead of link(), when the -s command flag is specified.

The following command creates a symbolic link at the command-line interface (shell):

ln -s target link_name

target is the relative or absolute path to which the symlink should point to. Usually the target will exist, although symbolic links may be created to non-existent targets. link_name is the desired name of the symbolic link.

After creating the symbolic link, it may generally be treated as an alias for the target. Any file system management commands (e.g., cp, rm) may be used on the symbolic link. Commands which read or write file contents will access the contents of the target file. The rm (delete file) command, however, removes the link itself, not the target file.

The POSIX directory listing application, ls, denotes symbolic links with an arrow after the name, pointing to the name of the target file (see following example), when the long directory list is requested (-l option). When a directory listing of a symbolic link that points to a directory is requested, only the link itself will be displayed. In order to obtain a listing of the linked directory, the path must include a trailing directory separator character ('/', slash).

$ mkdir -p /tmp/one/two
$ echo "test_a" >/tmp/one/two/a
$ echo "test_b" >/tmp/one/two/b
$ cd /tmp/one/two
$ ls -l
-rw-r--r-- 1 user group 7 Jan 01 10:01 a
-rw-r--r-- 1 user group 7 Jan 01 10:01 b

$ cd /tmp
$ ln -s /tmp/one/two three
$ ls -l /tmp/three
lrwxrwxrwx 1 user group 12 Jul 22 10:02 /tmp/three -> /tmp/one/two
$ ls -l /tmp/three/
-rw-r--r-- 1 user group 7 Jan 01 10:01 a
-rw-r--r-- 1 user group 7 Jan 01 10:01 b

$ cd three
$ ls -l
-rw-r--r-- 1 user group 7 Jan 01 10:01 a
-rw-r--r-- 1 user group 7 Jan 01 10:01 b
$ cat a
test_a
$ cat /tmp/one/two/a
test_a
$ echo "test_c" >/tmp/one/two/a
$ cat /tmp/one/two/a
test_c
$ cat /tmp/three/a
test_c

Storage of symbolic links

Early implementations of symbolic links stored the symbolic link information as data in regular files. The file contained the textual reference to the link’s target, and an indicator denoting it as a symbolic link.

This method was slow and an inefficient use of disk-space on small systems. An improvement, called fast symlinks, allowed storage of the target path within the data structures used for storing file information on disk (inodes). This space normally stores a list of disk block addresses allocated to a file. Thus, symlinks 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 is 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 significant gains in performance.

The vast majority of POSIX-compliant implementations use symlink inodes. However, the POSIX standard does not require the entire set of file status information common to regular files to be implemented for symlinks. This allows implementations to use other solutions, such as storing symlink data in directory entries.

The file system permissions of a symbolic link usually have relevance only to rename or removal operations of the link itself, not to the access modes of the target file which are controlled by the target file's own permissions.

The reported size of a symlink is the number of characters in the path it points to.

Mac OS aliases

In Mac OS (see Alias (Mac OS)) and some Linux distributions, applications or users can also employ aliases, which have the added feature of following the target, even if it is moved to another location on the same volume.

Microsoft Windows

NTFS Junction points

The Windows 2000 version of NTFS introduced reparse points, which enabled, among other things, the use of Volume Mount Points and junction points. Junction points are for directories only, and moreover, local directories only; junction points to remote shares are unsupported. The Windows 2000 and XP Resource Kits include a program called linkd to create junction points; a more powerful one named Junction was distributed by Sysinternals' Mark Russinovich.

Windows Vista symbolic link

Windows Vista supports symbolic links for both files and directories with the command line utility mklink. Unlike junction points, a symbolic link can also point to a file or remote Server Message Block (SMB) network path. Additionally, the NTFS symbolic link implementation provides full support for cross-filesystem links. However, the functionality enabling cross-host symbolic links requires that the remote system also support them, which effectively limits their support to Windows Vista and later Windows operating systems.

Symbolic links are designed to aid in migration and application compatibility with POSIX operating systems. Microsoft aimed for Vista's symbolic links to "function just like UNIX links". However, the implementation varies from Unix symbolic links in several ways; for example, Vista users must manually indicate when creating a symbolic link whether it is a file or a directory,. Vista has a limit of 31 symbolic links in a given path. Only users with the new Create Symbolic Link privilege, which only administrators have by default, can create symbolic links. If this is not the desired behavior, it must be changed in the Local Security Policy management console. In Vista, when the working directory path ends with a symbolic link, the .. path reference will refer to the parent directory of the symbolic link. In Unix, '..' refers to the parent directory of the target directory of a symbolic link.

Shortcuts

Symbolic links resemble shortcuts, which are supported by the graphical file browsers of some operating systems, but differ in a number of important ways. One difference is what type of software is able to follow them:

• Symbolic links are automatically resolved by the file system. Any software programs, upon accessing a symbolic link, will see the target instead, whether the program is aware of symbolic links or not.
• Shortcuts are treated like ordinary files by the file system and by software programs that are not aware of them. Only software programs that understand shortcuts (such as the Windows shell and file browsers) treat them as references to other files.

Another difference are the capabilities of the mechanism:

• Microsoft Windows shortcuts can only refer to a destination by an absolute path (starting from the root directory), whereas POSIX symbolic links can refer to destinations via either an absolute or a relative path. The latter is useful if both the location and destination of the symbolic link share a common path prefix, but that prefix is not yet known when the symbolic link is created (e.g., in an archive file that can be unpacked anywhere).
• Microsoft Windows application shortcuts contain additional metadata that can be associated with the destination, whereas POSIX symbolic links are just strings that will be interpreted as absolute or relative pathnames.

Cygwin symbolic links

Cygwin simulates POSIX-compliant symbolic links in the Microsoft Windows file system. It uses identical programming and user utility interfaces as Unix (see above), but creates Windows shortcuts (.lnk files) with additional information used by Cygwin at the time of symlink resolution. Cygwin symlinks are compliant with both Windows and POSIX standards.

Some differences exist, however. Cygwin has no way to specify shortcut-related information - such as working directory or icon - as there is no place for such parameters in ln -s command. To create standard Microsoft .lnk files Cygwin provides the mkshortcut utility

The Cygwin User's Guide has more information on this topic.

OS/2

In the OS/2 operating system, symbolic links resemble shadows in the graphical Workplace Shell.

Variable symbolic links

Symbolic links may be implemented in a context-dependent or variable fashion, such that the link points to varying targets depending on a configuration parameter, run-time parameter, or other instantaneous condition.

A variable or variant symbolic link is a symbolic link that has a variable name embedded in it. This allows some flexibility in filesystem order that is not possible with a standard symbolic link. Variables embedded in a symbolic links may include user and or environment specific information.

Operating systems that make use of variant symbolic links include NetBSD, DragonFly BSD and Domain/OS.

HP/Tru64 uses a context dependent symbolic link where the context is the cluster member number.

Pyramid Technology's OSx Operating System implemented conditional symbolic links which pointed to different locations depending on which universe a program was running in. The universes supported were AT&T's SysV.3 and the Berkeley Software Distribution (BSD 4.3). For example: if the ps command was in run the att universe, then the symbolic link for the directory /bin would point to /.attbin and the program /.attbin/ps would be executed. Whereas if the ps command was run in the ucb universe, then /bin would point to /.ucbbin and /.ucbbin/ps would be executed. Similar Conditional Symbolic Links were also created for other directories such as /lib, /usr/lib, /usr/include.

See also

• Symlink race, a security-vulnerability caused by symbolic links

References

1. Pathname resolution, POSIX.
2. Sysinternals Junction documentation
3. Symbolic Links, MSDN Library, Win32 and COM Development, 2008-01-18
4. CreateSymbolicLink Function, MSDN Library, Win32 and COM Development
5. Symbolic Link Programming Considerations, MSDN
6. Mark Russinovich: Inside the Windows Vista Kernel: Part 1 – File-based symbolic links, Microsoft Technet, February 2007.
7. Explanation of Surprising Unix Symlink Behavior, Debian Bug report logs
8. Microsoft .lnk files in Cygwin
9. Cygwin User's Guide, Cygwin.

External links

• Q & A: The difference between hard and soft links as applied to Linux

This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.

• Computer file systems