Symbolic link
From Wikipedia, the free encyclopedia
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.[1] Symbolic links first appeared in the 4.2BSD release of Berkeley Unix (1983). They are today 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: 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.
Contents |
[edit] Unix
To create a symbolic link in Unix, at the shell prompt, enter the following command:
ln -s target_filename symlink_filename
Replace target_filename with the relative or absolute path which the symlink will point to. Usually the target will exist, although you can create a symlink to a target which does not exist. Replace symlink_filename with the desired name of the symbolic link. The ln command then creates the symbolic link. After you've made the symbolic link, you can then treat symlink_filename as an alias for the target file. You can use normal file management commands (e.g., cp, rm) on the symbolic link. Commands which read or write the file contents will access the contents of the target file.
user@userbox:~/one$ cd two user@userbox:~/one/two$ ls a b user@userbox:~/one/two$ cd user@userbox:~$ ln -s ~/one/two three user@userbox:~$ cd three user@userbox:~/three$ ls a b user@userbox:~/three$ cd user@userbox:~$ cat ./one/two/a a
user@userbox:~$ echo "c" > ./one/two/a user@userbox:~$ cat ./three/a c
In Unix, symbolic links are created with the same ln shell command as hard links, but they behave very differently from the latter. Hard links are just (possibly multiple) names associated with a file and cannot exist without their associated file. When one hard link is moved, renamed or deleted, any other hard links referring to the same file data remain unaffected. Only when the last hard link to a file is deleted, the file content disappears. Unlike hard links, symbolic links can also point to directories and cross volumes.
[edit] Storage of symbolic links
Early implementations of symbolic links would store the symbolic link information in standard disk blocks, much like regular files. The file contained the textual reference to the link’s target, and an indicator denoting it as a symbolic link.
This arrangement proved somewhat slow, and could waste disk-space on small systems. An innovation called fast symlinks allowed storage of the link-text within the standard data structures used for storing file information on disk (inodes). This space generally serves to store the chain of disk blocks composing a file (60 bytes on the Unix File System). This simply means that users can reference shorter symbolic links quickly. Systems with fast symlinks often fall back to using the older method if the path and filename stored in symlink exceeds the available space in the inode, or for disk compatibility with other or older versions of the operating system. The original style has become retroactively termed slow symlinks.
Although storing the link value inside the inode saves a disk block and a disk read, the operating system still needs to parse the pathname information in the link, which always requires reading an additional inode and generally requires reading other — potentially many — directories, processing both the list of files and the inodes of each of them until it finds a match with the link pathname components. Only when a link points to a file inside the same directory do fast symlinks provide significant gains in performance.
The POSIX standard does not require very many struct stat values to have meaning for symlinks. This allows implementations to avoid symlink inodes entirely by storing the symlink data in directories. However, the vast majority of POSIX implementations (including all implementations currently in widespread use) do use symlink inodes.
The file-system permissions on the symbolic (or soft) link have no relevance: the permissions set on the file to which the symlink points control the access rights.
The size of a slow symlink exactly equals the number of characters in the path it points to. The size of a fast symlink is 0.
[edit] GoboLinux
One Linux distribution, GoboLinux, uses symlinks extensively in an effort to redesign the file system hierarchy. This offers the opportunity to create a more intuitive directory tree and to reorganize without having to redesign the kernel itself.
[edit] Mac OS
[edit] Aliases
In addition to the usual Unix symbolic links, Mac OS can employ aliases, which have the added feature of working even if the target file moves to another location on the same disk. A similar functionality also exists in some Linux distributions.
[edit] Windows
[edit] 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.[2] 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.
[edit] 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 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"[3]. However, the implementation varies from Unix symlinks in several ways; for example, Vista users must manually indicate when creating a symbolic link whether it is a file or directory,[4] and there is a limit of 31 symlinks in a given path.[5]. Additionally, only users with the new Create Symbolic Link privilege, which only administrators have by default, can create symbolic links;[6] if this is not the desired behavior, it must be changed in the Local Security Policy management console.
[edit] 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:
- References to symbolic links are resolved by the file system in the operating-system kernel, and therefore any application software that knows nothing about symbolic links will follow them automatically.
- Application shortcuts are treated by the filesystem in the operating-system kernel and by applications that know nothing about them like ordinary files, and only applications that know about them (usually special 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.
[edit] Cygwin symlinks
Cygwin uses method to simulate POSIX-compliant symbolic links. Using command:
ln -s target_filename symlink_filename
creates Windows shortcut (.lnk file) with additional information used by Cygwin ad the time of symlinks execution. Doing so makes Cygwin symlinks compliant both with Windows and POSIX standard.
The difference is that in Windows such symlink is treated like regular shortcut (which in fact it is) so it causes different behaviour when such file/directory is used from Cygwin or Windows command line.
Another problem is that Cygwin while creating its own symlink 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 mkshortcut utility[7]
For more information please check Cygwin User's Guide[8]
[edit] Others
Symbolic links also resemble shadows in the graphical Workplace Shell of the OS/2 operating system.
[edit] Variant symlinks
A variant symlink is a symbolic link that has a variable name embedded in it. This can allow some clever tricks to be performed that are not possible with a standard symlink. Variables embedded in the symlinks can include user and or environment specific information among other things.
Operating systems that make use of variant symlinks include Domain/OS and DragonFly BSD.
[edit] See also
- Hard link
- ln (Unix), the ln command, used with the -s option to create new symbolic links on Unix-like systems
- Symlink race, a security-vulnerability caused by symbolic links
[edit] External links
- Q & A: The difference between hard and soft links Detailed and easy to understand
[edit] References
- ^ Pathname resolution, POSIX.
- ^ Sysinternals Junction documentation
- ^ Symbolic Links, MSDN Library, Win32 and COM Development, 2008-01-18
- ^ CreateSymbolicLink Function, MSDN Library, Win32 and COM Development
- ^ Symbolic Link Programming Considerations, MSDN
- ^ Mark Russinovich: Inside the Windows Vista Kernel: Part 1 – File-based symbolic links, Microsoft Technet, February 2007.
- ^ [1] Microsoft .lnk files in Cygwin
- ^ [2] Cygwin User's Guide, Cygwin.
This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.
