Символические ссылки в компьютерных системах

Any file that contains a reference to another file or directory
the Microsoft data exchange format

In computing, a symbolic link (also symlink or soft link) is a file whose purpose is to point to a file or directory (called the "target") by specifying a path thereto. Symbolic links are supported by POSIX and by most Unix like operating systems, such as FreeBSD, Linux, and macOS. Limited support also exists in Windows 7 and Windows Vista, and to some degree in Windows 2000 and Windows XP in the form of shortcut files. CTSS on IBM 7090 had files linked by name in 1963. By 1978 minicomputer operating systems from DEC, and in Data General's RDOS included symbolic links.

A symbolic link contains a text string that is automatically interpreted and followed by the operating system as a path to another file or directory. This other file or directory is called the "target". The symbolic link is a second file that exists independently of its target. If a symbolic link is deleted, its target remains unaffected. If a symbolic link points to a target, and sometime later that target is moved, renamed or deleted, the symbolic link is not automatically updated or deleted, but continues to exist and still points to the old target, now a non existing location or file. Symbolic links pointing to moved or non existing targets are sometimes called broken, orphaned, dead, or dangling. Symbolic links are different from hard links. Hard links do not link paths on different volumes or file systems, whereas symbolic links may point to any file or directory irrespective of the volumes on which the link and target reside. Hard links always refer to an existing file, whereas symbolic links may contain an arbitrary path that does not point to anything. Symbolic links operate transparently for many operations: programs that read or write to files named by a symbolic link will behave as if operating directly on the target file. However, they have the effect of changing an otherwise hierarchic filesystem from a tree into a directed graph, which can have consequences for such simple operations as determining the current directory of a process. Even the Unix standard for navigating to a directory's parent directory no longer works reliably in the face of symlinks. Some shells heuristically try to uphold the illusion of a tree shaped hierarchy, but when they do, this causes them to produce different results from other programs that manipulate pathnames without such heuristic, relying on the operating system instead. Programs that need to handle symbolic links specially (e. g., shells and backup utilities) thus need to identify and manipulate them directly. 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, 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.

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 the file mode bits indicated that the type of the file is 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 significantly better performance than other symlinks. The vast majority of POSIX compliant 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 symlinks. This allows implementations to use other solutions, such as storing symlink 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 and lchflags system calls respectively. The reported size of a symlink is the number of characters in the path it points to.

A traditional Unix filesystem has a tree structure, however symbolic links allow it to contain loops. 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". 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. 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). 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. 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 and operate on the current logical directory. 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, and may return completely different results.

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 to create junction points; a more powerful one named Junction was distributed by Sysinternals' Mark Russinovich. Not all standard applications support reparse points. Most noticeably, Backup suffers from this problem and will issue an error message 0x80070003 when the folders to be backed up contain a reparse point.

Symbolic link Junction Hard link When the link is deleted The target remains unchanged The target is deleted A reference counter is decremented. When it reaches 0, the target is deleted. When target is moved The link becomes invalid The link becomes invalid The link remains valid Relative path Can be on a different volume? Link to files on Windows rowspan="2" Link to folders on Windows Link to files on Unix Link to folders on Unix

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.

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.