Symbolic link

In computing, a symbolic link (a.k.a. symlink or soft link) is a file that refers to a file system item (such as a file or a directory) by storing a path to it.^[1] In a POSIX-conforming system, a file is any Unix file type.

A symbolic link is an independent file that stores a file system path that, except for special situations, is treated as the file system item to which the path refers; the target. If a symbolic link is deleted, its target is not affected. If the target is moved, renamed or deleted, the symbolic link is not automatically updated or deleted. Its target path would point to nothing and might be described as broken, orphaned, dead, or dangling.

Symbolic links were introduced in 1982 in 4.1a BSD Unix from U.C. Berkeley.^[2] POSIX defines the symbolic link as found in most Unix-like operating systems, such as FreeBSD, Linux, and macOS. Windows (starting with Windows 10) supports symbolic links.^[3] CTSS on IBM 7090 supported files linked by name in 1963.^[4][5][6] By 1978, minicomputer operating systems from DEC, and in Data General's RDOS included symbolic links.

Due to its nature, the symbolic link feature causes a hierarchical file system to be a directed graph instead of a tree, which can affect otherwise simple operations. For example, navigating to a directory's parent may not work reliably with symbolic links. Some Unix shells heuristically try to uphold the illusion of a tree-shaped hierarchy, but this causes them to produce different results compared to other programs that manipulate paths without such heuristics; relying on the operating system instead.^[7]

Some UNIX-based systems use symbolic links to restructure the file system hierarchy. This is accomplished with several mechanisms, such as variant, context-dependent symbolic links. Thus, symbolic links allow for a more intuitive or application-specific directory structure and to reorganize the file system without redesigning core system functions and utilities.

The symbolic link differs from the hard link. A hard link cannot link to a target on a different volume or file system, but a symbolic link can. A hard link always refers to an existing target, whereas a symbolic link might be a path to nothing.

Generally, in a UNIX-based system, a symbolic link is created with the symlink() system call^[8]. By default, the ln shell command uses the link() ^[9] system call, which creates a hard link. When the -s option is specified, the symlink() system call is used instead, creating a symbolic link.

The following creates a symbolic link to target path target_path. Typically, the target will exist, although a symbolic link may be created to a non-existent target. link_path is the path of the symbolic link to create.

ln -s target_path link_path

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,^[10] lchown^[11] and readlink^[12] commands apply directly to link file; not their targets. Via system calls, a program (e.g., ls, find) can report on symbolic links instead of their targets. Because the rename() and unlink() system calls are coded to operate directly on symbolic links, the rm and mv commands (which use these system calls) affect the symbolic link itself instead of being applied to the symbolic link target. The cp command has options that allow either the symbolic link or the target to be copied.

The ls command, for long list output (-l), denotes a symbolic link by appending an arrow and the target name after the link name. The following creates a link named bar to file foo.

$ touch foo
$ ln -s foo bar
$ ls -l bar
lrwxrwxrwx 1 user group 3 Aug  4 18:40 bar -> foo

The same applies for a directory. For example:

$ mkdir foo-dir
$ touch foo-dir/a
$ ls -l foo-dir
-rw-r--r-- 1 user group 7 Jan 01 10:01 a
$ ln -s foo-dir link-to-foo-dir
$ ls -l link-to-foo-dir
lrwxrwxrwx 1 user group 12 Jul 22 10:02 link-to-foo-dir -> foo-dir/

If the directory name ends with a slash, then ls navigates the link to show the directory contents instead. For example:

$ ls -l link-to-foo-dir/
-rw-r--r-- 1 user group 7 Jan 01 10:01 a

Early implementations stored the link path in a regular file. The file contained the target path as text, and the file mode bits indicated the file as a symbolic link.

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 normally 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.

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

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. Some operating systems, such as FreeBSD, offer the ability to modify file permissions and filesystem attributes of a symbolic link, through lchmod^[13] and lchflags^[14] system calls respectively.

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

Windows provides a number of technologies that are similar to if not the same as UNIX-based symbol links.

NTFS 3.1 introduced support for symbolic links for any type of file. It was included with Windows XP, but was only enabled by default for kernel-mode apps. Windows Vista and later versions of Windows enabled support for symbolic links to user-mode applications. The mklink internal command of Windows Command Prompt can create symbolic links. Third-party drivers are required to enable support for NTFS symbolic links in Windows XP.^[15] 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.

Symbolic links are designed to aid in migration and application compatibility with POSIX operating systems. Microsoft aimed for Windows Vista's symbolic links to "function just like UNIX links".^[16] However, the implementation differs from Unix symbolic links in several ways. For example, Windows Vista users must manually indicate when creating a symbolic link whether it is a file or a directory.^[17] Windows 7 and Vista support a maximum of 31 reparse points (and therefore symbolic links) for a given path (i.e. any given path can have at most 31 indirections before Windows gives up).^[18] Only users with the new Create Symbolic Link privilege, which only administrators have by default, can create symbolic links.^[19] If this is not the desired behavior, it must be changed in the Local Security Policy management console. Additionally, NTFS symbolic links to files are distinct from NTFS symbolic links to directories and therefore cannot be used interchangeably, unlike on POSIX where the same symbolic link can refer to either files or directories.

In Windows Vista and later, when the working directory path ends with a symbolic link, the current parent path reference, .., will refer to the parent directory of the symbolic link rather than that of its target. This behavior is also found at the shell level in at least some POSIX systems, including Linux, but never in accessing files and directories through operating system calls. For instance, bash builtin commands pwd and cd operate on the current logical directory. pwd is often used in scripts to determine the actual current working directory. When any path is used with a system call, any use of .. will use the actual filesystem parent of the directory containing the .. pseudo-directory entry. So, cd ..; cat something and cat ../something may return completely different results.

The following creates a symbolic link called "Downloads" at "E:\" that points to the Downloads folder in the user's profile. This works in Command Prompt only as mklink is a built-in shell command.

mklink /D E:\Downloads %UserProfile%\Downloads

This does the same, but in PowerShell.

New-Item -Path 'E:\Downloads' -ItemType 'SymbolicLink' -Value "$Env:UserProfile\Downloads"

The Windows 2000 introduced NTFS reparse points, which enabled the use of NTFS volume mount points and junction points. Junction points are soft links to machine-local directories (junction points to remote shares are unsupported).^[20] The Windows 2000 and XP Resource Kits include a program called linkd.exe to create junction points. A more powerful one named Junction.exe is distributed as a part of Microsoft Sysinternals Suite.^[20] The tools introduced above (mklink and New-Item) also support creating junction points.

Not all standard applications support reparse points. Most noticeably, Windows Backup suffers from this problem and will issue an error message 0x80070003 when the folders to be backed up contain a reparse point.^[21]

Shortcuts, which are supported by the graphical file browsers of some operating systems, may resemble symbolic links 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 program, 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.

The mechanisms also have different capabilities:

• Windows shortcuts normally 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 symbolic link and its target share some common ancestor path which is not known at creation (e.g., in an archive file that can be unpacked anywhere).
• 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.
• Unlike symbolic links, Windows shortcuts maintain their references to their targets even when the target is moved or renamed. Windows domain clients may subscribe to a Windows service called Distributed Link Tracking^[22] to track the changes in files and folders to which they are interested. The service maintains the integrity of shortcuts, even when files and folders are moved across the network.^[23] Additionally, in Windows 9x and later, Windows shell tries to find the target of a broken shortcut before proposing to delete it.

Almost like shortcuts, but transparent to the Windows shell.^[24] They are implemented as ordinary folders (which need to have the read only and/or system attribute^[25]) containing a shortcut named target.lnk which refers to the target and a (hidden) desktop.ini with (at least) the following contents:

[.ShellClassInfo]
CLSID2={0AFACED1-E828-11D1-9187-B532F1E9575D}

Folder shortcuts are created and used from the Windows shell in the network neighborhood for example.

The shell objects^[26] or shell folders are defined in the Windows registry and can be used to implement a sort of symbolic link too. Like folder shortcuts, they are transparent to the Windows shell.

A minimal implementation is (the CLSID {00000000-0000-0000-0000-000000000000} is used as a placeholder):

[HKEY_CLASSES_ROOT\CLSID\{00000000-0000-0000-0000-000000000000}]
@="display name"
[HKEY_CLASSES_ROOT\CLSID\{00000000-0000-0000-0000-000000000000}\DefaultIcon]
@="..." ; path to icon
[HKEY_CLASSES_ROOT\CLSID\{00000000-0000-0000-0000-000000000000}\InProcServer32]
@="%SystemRoot%\\System32\\ShDocVw.Dll"
"ThreadingModel"="Apartment"
[HKEY_CLASSES_ROOT\CLSID\{00000000-0000-0000-0000-000000000000}\Instance]
"CLSID"="{0AFACED1-E828-11D1-9187-B532F1E9575D}"
[HKEY_CLASSES_ROOT\CLSID\{00000000-0000-0000-0000-000000000000}\Instance\InitPropertyBag]
"Attributes"=hex:15,00,00,00
"Target"="..." ; absolute (WITHOUT "TargetKnownFolder" or "TargetSpecialFolder" only)
               ; or relative path to target
"TargetKnownFolder"="{guidguid-guid-guid-guid-guidguidguid}" ; GUID of target folder, Windows Vista and later
"TargetSpecialFolder"="0x00xy" ; CSIDL of target
[HKEY_CLASSES_ROOT\CLSID\{00000000-0000-0000-0000-000000000000}\ShellFolder]
"Attributes"=hex:00,00,00,00

The My Documents folder on the Desktop as well as the Fonts and the Administrative Tools folders in the Control Panel are examples of shell objects redirected to file-system folders.

Cygwin simulates POSIX-conforming symbolic links in the 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 symbolic link resolution. Cygwin symbolic links comply with the POSIX standard in terms of how they are resolved, and with Windows standards in terms of their on-disk representation.

Additionally, Cygwin can be set up to support native Windows symbolic links which can be used out of Cygwin without restrictions.^[27] This requires:

1. Changing the CYGWIN environment variable to contain winsymlinks:native;
2. Running the Cygwin with elevated rights because Windows restricts the creation of symbolic links to privileged users

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 and readshortcut utilities.^[28]

The Cygwin User's Guide has more information on this topic.^[27] MSYS2, which is based on Cygwin, has a similar set of winsymlinks settings but defaults to copying the files.^[29]

The following table compares various aspects of the symbolic link (both UNIX-based and Windows), junction point (NTFS) and hard link (UNIX-based).

Implementations of features similar to symbolic links.

MIT Compatible Time-Sharing System c. 1963 and Incompatible Timesharing System both have linked files where the name of the target file is specified in a directory entry.^[4][5][6]

Data General's RDOS for its Nova computers supports "link entries", which are directory entries that contain both the name of the entry and the name of another file, so that a reference to a file using the name of the entry refers to the other file.^[31]

The command creating symbolic links is makelink, which is also used for hard links. Internally the dos.library returns an error code indicating that a target is a soft link if you try to perform actions on it that are only legal for a file, and applications that wish to follow the symbolic link then needs to explicitly make a call to follow the link and retry the operation. The AmigaDOS shell will follow links automatically.

In Mac OS, 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. This is not to be confused with the shell command alias.

In the OS/2 operating system, symbolic links somewhat resemble shadows in the graphical Workplace Shell. However, shadows, due to the fully object-oriented System Object Model, are considerably more powerful and robust than a simple link. For example, shadows do not lose their capabilities when renamed or when either the object or subject of the link is relocated.^[32]

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 link may include user and environment specific information.

Operating systems that make use of variant symbolic links include NetBSD, DragonFly BSD, Domain/OS.^[33][34][7] 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&Ts's SysV.3 and the Berkeley Software Distribution (BSD 4.3). For example: if the ps command was run in 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.^[35]

• Symlink race — a security-vulnerability caused by symbolic links
• freedup — generates links between identical data automatically
• Pointer (computer programming)

Wikibooks has a book on the topic of: Linux commands

• Q & A: The difference between hard and soft links as applied to Linux
• Junction: maintain NTFS junction points (for Windows 2000 and above)
• FSUtil Hardlink: Microsoft Technet page on using the command-line tool FSUtil to create hardlinks (for Windows 2000 and above)
• Symbolic Drivers for Windows XP (in Japanese): file system drivers to enable Symbolic Links for Windows XP (also mirrored on Link Shell Extension site). Sources available.