Symbolic link
In computing, a symbolic link is a special computer file that refers to another file or directory by storing a path to it, thus providing an alternative access path without duplicating the target's content. Apps that use operating system services may treat a symbolic link like other files or directories, and would not know that it is a symbolic link unless they investigate its nature. A symbolic link could break if its target is moved or deleted.
Symbolic links are supported in Unix-like operating systems and Microsoft Windows, although they impose varying limitations on them. Alternatives to symbolic links include hard links, shortcut files, and Windows shell objects.
Overview
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. The symbolic link differs from the hard link. The latter cannot link to a target on a different volume or file system, but the former can. A hard link always refers to an existing target, whereas a symbolic link might be a path to nothing.Symbolic links were introduced in 1982 in 4.1a BSD Unix. The POSIX standard defines the symbolic link as found in most Unix-like operating systems, such as FreeBSD, Linux, and macOS. CTSS on IBM 7090 supported files linked by name in 1963. By 1978, some symbolic links were supported in minicomputer operating systems from DEC, and Data General's RDOS.
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 has a variable name embedded in its path definition, allowing some flexibility that is not possible with a standard symbolic link. NetBSD, DragonFly BSD, and Domain/OS support such links. Tru64 uses a context dependent symbolic link where the context is the cluster member number. Pyramid Technology's OSx operating system supports conditional symbolic links.
The aforesaid context-dependent symbolic links serve to restructure the file system hierarchy, allow for a more intuitive or application-specific directory structure, and to reorganize the file system without redesigning core system functions and utilities. Because of 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.
Windows 95 also had a similar intuitiveness concern, but instead of adopting symbolic links, created the Windows shell, special folders, and shortcut files.
Unix-like
Use
In a Unix-like OS, theln shell command can create either a hard link or a symbolic link. 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 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 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. andlchflags 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. 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.
Windows
Microsoft Windows support symbolic links in the NTFS and ReFS file systems, as well as the Windows kernel namespace.NTFS junctions and volume mount points
Starting with Windows 2000, NTFS supports junction points, also known as soft links. Junction points are similar to symbolic links, but only link to other directories, not files. They are implemented via NTFS reparse points. Windows 7 and Vista support a maximum of 31 reparse points for a given path.Also starting with 2000, NTFS supports volume mount points. Normally, Windows volumes are assigned a drive letter. Volume mount points act like a symbolic link to the root of another volume that is not assigned a drive letter.
NTFS symbolic link
version 3.1 introduced support for symbolic links. Windows XP partially implemented NTFS 3.1, leaving out symbolic links. Thus, a third-party driver is required to enable support for NTFS symbolic links in Windows XP. Windows Vista and later enabled support for symbolic links. Unlike NTFS junction points, a symbolic link can also point to a file or remote Server Message Block network path. Additionally, the NTFS symbolic link implementation provides full support for cross-volume links. However, the functionality enabling cross-host symbolic links requires that the remote system to 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". To create a symbolic link, the user account must possess the new "Create Symbolic Link" privilege, which, by default, only admins have. 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.
Users could use Command Prompt or PowerShell to create symbolic links. 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
The
/D switch in this command requests a junction point instead of a file symbolic link. This command succeeds even if the target doesn't exist.The following PowerShell command also creates a symbolic link with the same source and target as above:
New-Item -Path 'E:\Downloads' -ItemType 'SymbolicLink' -Value "$Env:UserProfile\Downloads"
In addition to file and folders, NTFS symbolic links can point to an alternate data stream. The following example creates a symbolic link called "
Test.txt" that points the "Zone.Identifier:$DATA" alternative stream of a file called "npcap-1.83.exe". New-Item -Path "E:\Test.txt" -ItemType 'SymbolicLink' -Value 'E:\npcap-1.83.exe:Zone.Identifier:$DATA'
CreateSymbolicLink function of Windows API, introduced in 2008. It can create both file and directory symbolic links. Much later, in 2021, Microsoft introduced File.CreateSymbolicLink and Directory.CreateSymbolicLink methods to.NET 6. They are free and open-source.