Editing Symbolic link

{{Short description|Any file that contains a reference to another file or directory}}
{{for|the Microsoft data exchange format|Symbolic Link (SYLK)}}

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 (computing)|path]] thereto.<ref>[https://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11 Pathname resolution], [[POSIX]].</ref>

Symbolic links are supported by [[POSIX]] and by most [[Unix-like]] [[operating system]]s, such as [[FreeBSD]], [[Linux]], and [[macOS]]. Support also exists in [[Windows 10]] and [[Windows 11|11]].<ref name="windows-support">{{cite web|url=https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/mklink |title=Windows mklink Command}}</ref> [[Compatible Time-Sharing System#File system|CTSS]] on [[IBM 7090]] had files linked by name in 1963.<ref name="50th">{{cite web |url=https://multicians.org/thvv/compatible-time-sharing-system.pdf |title=Compatible Time-Sharing System (1961-1973): Fiftieth Anniversary Commemorative Overview |editor-last1=Walden |editor-first1=David |editor-last2=Van Vleck |editor-first2=Tom |editor2-link=Tom Van Vleck |date=2011 |publisher=IEEE Computer Society |access-date=February 20, 2022 |quote=As CTSS developed, we provided ways for users to share their files on disk, through “common files” and “linking,”}}</ref><ref name="ctsspg69">{{cite web |url=http://www.bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide_Dec69.pdf |title=The Compatible Time-Sharing System, A Programmer's Guide |editor-last=Crisman |editor-first=Patricia A. |date=December 31, 1969 |publisher=The M.I.T Computation Center |access-date=March 10, 2022 |quote=U.F.D. entries that point to other U.F.D. entries instead of to the file itself}}</ref><ref name="ctsspg63">{{cite web |url=https://www.ibiblio.org/apollo/Documents/CTSS_ProgrammersGuide.pdf |title=The Compatible Time-Sharing System A Programmer's Guide |first1=F. J. |last1=Corbato |authorlink1=Fernando J. Corbató |first2=M. M. |last2=Daggett |first3=R. C. |last3=Daley |first4=R. J. |last4=Creasy |first5=J. D. |last5=Hellwig |first6=R. H. |last6=Orenstein |first7=L. K. |last7=Korn |date=1963 |publisher=MIT |access-date=November 29, 2022 |quote=Link: The format is similar to Copy. The specified file is not copied}}</ref> By 1978 minicomputer operating systems from [[Digital Equipment Corporation|DEC]], and in Data General's [[Data General RDOS|RDOS]] included symbolic links.

==Overview==
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 link]]s. Hard links do not link paths on different [[volume (computing)|volumes]] or [[file system]]s, 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 (graph theory)|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 [[Unix shell|shells]] [[heuristic]]ally 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.<ref name=":0">{{cite conference |first=Rob |last=Pike |author-link=Rob Pike |title=Lexical file names in Plan 9 or getting dot-dot right |conference=Proc. [[USENIX]] Annual Tech. Conf. |year=2000 |url=https://static.usenix.org/events/usenix2000/general/full_papers/pikelex/pikelex.pdf}}</ref>
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.

==POSIX and Unix-like operating systems==
In [[POSIX]]-compliant operating systems, symbolic links are created with the <code>symlink</code><ref>[https://pubs.opengroup.org/onlinepubs/9699919799/functions/symlink.html symlink, symlinkat]. IEEE Std 1003.1, 2013 Edition.</ref> system call.  The <code>[[ln (Unix)|ln]]</code> shell command normally uses the <code>link</code><ref>[https://pubs.opengroup.org/onlinepubs/9699919799/functions/link.html link, linkat]. IEEE Std 1003.1, 2013 Edition.</ref> system call, which creates a [[hard link]].  When the <code>ln ''-s''</code> flag is specified, the symlink() system call is used instead, creating a symbolic link. Symlinks were introduced in 1982 in [[Berkeley Software Distribution|4.1a BSD Unix]] from [[Computer Systems Research Group|U.C. Berkeley]].<ref>{{cite web |author1=Bill Joy |author2=Sam Leffler |author1-link=Bill Joy |author2-link=Samuel J. Leffler |title=Surviving with 4.1a bsd |website=[[GitHub]] |url=https://github.com/dspinellis/unix-history-repo/blob/BSD-4_1c_2/usr/man/man0/changes.4-82#L28 |access-date=8 September 2023 |quote=It also includes a few other features which you may find useful, such as ‘‘symbolic links’’ and an improved group scheme.}}</ref>

The following command creates a symbolic link at the [[command-line interface]] (shell):
<pre>
 ln -s target_path link_path
</pre>
{{mono|target_path}} is the relative or absolute path to which the symbolic link should point.  Usually the target will exist, although symbolic links may be created to non-existent targets. {{mono|link_path}} is the path of the symbolic link.

After creating the symbolic link, some operations can be used to treat it as an alias for the target. However, the <code>lstat</code>,<ref>[https://pubs.opengroup.org/onlinepubs/9699919799/functions/fstatat.html fstatat, lstat, stat - get file status] IEEE Std 1003.1, 2013 Edition.</ref> <code>lchown</code><ref>[https://pubs.opengroup.org/onlinepubs/9699919799/functions/lchown.html lchown - change the owner and group of a symbolic link] IEEE Std 1003.1, 2013 Edition.</ref> and <code>readlink</code><ref>[https://pubs.opengroup.org/onlinepubs/9699919799/functions/readlink.html readlink, readlinkat - read the contents of a symbolic link] IEEE Std 1003.1, 2013 Edition.</ref> operations are unique to symbolic links and do not apply to the target; by using those system calls, programs that examine the file system (e.g., <code>[[ls]]</code>, <code>[[find (Unix)|find]]</code>) can report on symbolic links (instead of their targets, if any).  Because the <code>rename</code> and <code>[[unlink (Unix)|unlink]]</code> system calls are coded to operate directly on symbolic links, file system management commands (e.g.,  <code>[[rm (Unix)|rm]]</code>, <code>[[mv (Unix)|mv]]</code>) affect the symbolic link itself (instead of being applied to the symbolic link target, if any).  The <code>rm</code> (delete file) command removes the link itself, not the target file. Likewise, the <code>mv</code> command moves or renames the link, not the target. The <code>[[cp (Unix)|cp]]</code> command has options that allow either the symbolic link or the target to be copied. Commands which read or write file contents will access the contents of the target file.

The POSIX directory listing application, <code>ls</code>, 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 (<code>-l</code> 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).
 
Note: In the example below do not create "three" directory before creation of link in /tmp directory.
<syntaxhighlight lang="console">
$ 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 three
lrwxrwxrwx 1 user group 12 Jul 22 10:02 /tmp/three -> /tmp/one/two
$ ls -l 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 a
test_c
</syntaxhighlight>

===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 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 storage|disk-space]] on small systems.  An improvement, called '''fast symlinks''', allowed storage of the target path within the [[data structure]]s used for storing file information on disk ([[inode]]s). This space normally stores a list of disk [[Block (data storage)|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 [[retronym|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 <code>lchmod</code><ref>{{cite web |url=https://www.freebsd.org/cgi/man.cgi?query=lchmod&apropos=0&sektion=2&manpath=FreeBSD+11.0-RELEASE&arch=default&format=html |series=Manual pages for FreeBSD 11 |title=lchmod(2)}}</ref> and <code>lchflags</code><ref>{{cite web |url=https://www.freebsd.org/cgi/man.cgi?query=lchflags&apropos=0&sektion=2&manpath=FreeBSD+11.0-RELEASE&arch=default&format=html |series=Manual pages for FreeBSD 11 |title=lchflags(2)}}</ref> system calls respectively.

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

===Error handling===
A traditional [[Unix filesystem]] has a tree structure,<ref name="Ritchie">{{cite journal |last1=Ritchie |first1=D.M. |author-link1=Dennis Ritchie |last2=Thompson  |first2=K. |author-link2=Ken Thompson |title=The UNIX Time-Sharing System |journal=Bell System Tech. J. |volume=57 |issue=6 |pages=1905–1929 |date= July 1978 |doi=10.1002/j.1538-7305.1978.tb02136.x |citeseerx=10.1.1.112.595}}</ref> however symbolic links allow it to contain loops.<ref name=":0"/> <!-- ELOOP is the current approach but I used a MicroSoft Xenix which tried to do symlink loop detection at symlink creation time as opposed  to runtime. Naturally you could create two file systems each with a non-looping symlink and then mount them to align those symlinks into a loop and hang program that tried to open them. I don't know the origin of that bug yet. I have found that there is no sign of BSD code in SCCS that has symlinks while lacking ELOOP.  Tested with: "sccsdiff -u -r4.8 -r4.9 SCCS/s.ufs_nami.c"  That leaves either the Xenix bug being written by someone at MS or something MS bought. Come to think of it, maybe BSD wasn't the first UNIX to have symlinks added to it. -->

==Microsoft Windows==

===NTFS symbolic link===
{{Main|NTFS symbolic link}}
[[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 <code>mklink</code> internal command of [[Windows command prompt|Windows Command Prompt]] can create symbolic links. Third-party drivers are required to enable support for NTFS symbolic links in Windows XP.<ref>{{cite web |url=https://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html#symboliclinksforwindowsxp |title=Link Shell Extension website |website=Link Shell Extension website}}</ref> Unlike [[NTFS junction point|junction point]]s, 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".<ref>[https://msdn.microsoft.com/en-us/library/aa365680.aspx Symbolic Links], MSDN Library, Win32 and COM Development, 2008-01-18</ref> 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.<ref>{{Cite web|title=CreateSymbolicLinkA function (winbase.h)|url=https://msdn.microsoft.com/en-us/library/aa363866.aspx |website=[[MSDN]]|date=June 2023 }}</ref> Windows 7 and Vista support a maximum of 31 [[reparse point]]s (and therefore symbolic links) for a given path (i.e. any given path can have at most 31 indirections before Windows gives up).<ref>[https://msdn.microsoft.com/en-us/library/aa365460(VS.85).aspx Symbolic Link Programming Considerations], MSDN</ref> Only users with the new ''Create Symbolic Link'' privilege, which only administrators have by default, can create symbolic links.<ref>Mark Russinovich: [https://www.microsoft.com/technet/technetmag/issues/2007/02/VistaKernel/default.aspx Inside the Windows Vista Kernel: Part 1] – File-based symbolic links, Microsoft Technet, February 2007.</ref> 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, {{code|..}}, 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 {{code|pwd}} and {{code|cd}} operate on the current logical directory.  {{code|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 {{code|..}} will use the actual filesystem parent of the directory containing the {{code|..}} pseudo-directory entry.  So, {{code|cd ..; cat something}} and {{code|cat ../something}} may return completely different results.

==== Examples ====
The following examples both create a symbolic link called "Downloads" at "E:\" that points to the Downloads folder in the current user's profile.

* The first example works in [[Windows command prompt|Windows Command Prompt]] only because <code>mklink</code> is an internal command.
: <syntaxhighlight lang="batch" inline="">
mklink /D E:\Downloads %UserProfile%\Downloads
</syntaxhighlight>

* The second example works in [[PowerShell]] only because New-Item is an internal cmdlet.
: <syntaxhighlight lang="ps1" inline="">
New-Item -Path 'E:\Downloads' -ItemType 'SymbolicLink' -Value "$Env:UserProfile\Downloads"
</syntaxhighlight>

===NTFS junction points===
{{Main|NTFS junction point}}
The [[Windows 2000]] introduced [[NTFS reparse point]]s, which enabled the use of [[NTFS volume mount point]]s and junction points. Junction points are soft links to machine-local directories (junction points to remote shares are unsupported).<ref name=":99" /> The Windows 2000 and XP Resource Kits include a program called <code>linkd.exe</code> to create junction points. A more powerful one named <code>Junction.exe</code> is distributed as a part of Microsoft Sysinternals Suite.<ref name=":99">{{Cite web |url=https://learn.microsoft.com/en-us/sysinternals/downloads/junction#junction-v107 |title=Junction v1.07 |work=Microsoft Sysinternals |via=Microsoft Learn |publisher=[[Microsoft]] |author-first=Mark |author-last=Russinovich |author-link=Mark Russinovich |date=4 July 2016}}</ref> The tools introduced above (<code>mklink</code> and <code>New-Item</code>) 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.<ref>{{Cite web |url=https://support.microsoft.com/kb/973455 |title=Windows backup or restore errors 0x80070001, 0x81000037, or 0x80070003 |work=Microsoft Support |publisher=Microsoft |date=17 April 2018}}</ref>

===Shortcuts===
[[Computer shortcut|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:
* [[Microsoft 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 symlink 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).
* 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.
* 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<ref>{{cite web | url=https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/distributed-link-tracking-on-domain-controller | title=Distributed Link Tracking on domain controllers - Windows Server | date=23 February 2023 }}</ref> 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.<ref>{{cite web
  |title=Distributed Link Tracking and Object Identifiers
  |url=https://msdn.microsoft.com/en-us/library/aa363997%28v=VS.85%29.aspx
  |work=[[Microsoft Developers Network]]
  |publisher=Microsoft Corporation
  |access-date=30 June 2011
  |date=20 March 2011
}}</ref> Additionally, in Windows 9x and later, [[Windows shell]] tries to find the target of a broken shortcut before proposing to delete it.

====Folder shortcuts====
Almost like shortcuts, but transparent to the Windows shell.<ref>{{cite web|url=https://msdn.microsoft.com/en-us/library/bb776817.aspx|title=Specifying a Namespace Extension's Location|website=msdn.microsoft.com|date=11 January 2008 |access-date=23 March 2018}}</ref> They are implemented as ordinary folders (which need to have the ''read only'' and/or ''system'' attribute<ref>{{Cite web|title=You cannot view or change the Read-only or the System attributes of folders in Windows Server 2003, in Windows XP, in Windows Vista or in Windows 7|url=https://support.microsoft.com/kb/256614/en-us |access-date=2021-07-08|website=support.microsoft.com}}</ref>) containing a shortcut named ''target.lnk'' which refers to the target and a (hidden) ''desktop.ini'' with (at least) the following contents:
<syntaxhighlight lang="ini">
[.ShellClassInfo]
CLSID2={0AFACED1-E828-11D1-9187-B532F1E9575D}
</syntaxhighlight>

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

===Shell objects===
The ''shell objects''<ref>[https://msdn.microsoft.com/library/ms997573.aspx Creating Shell Extensions with Shell Instance Objects]. msdn.microsoft.com</ref> 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):

<syntaxhighlight lang="registry">
[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
</syntaxhighlight>
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 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 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.<ref name="cygwin">{{Cite web|title=Chapter 3. Using Cygwin|url=https://www.cygwin.com/cygwin-ug-net/using.html |access-date=2021-07-08|website=www.cygwin.com}}</ref> This requires:
# Changing the CYGWIN environment variable to contain {{tt|winsymlinks:native}};
# 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 <code>ln -s</code> command. To create standard Microsoft .lnk files Cygwin provides the <code>mkshortcut</code> and <code>readshortcut</code> utilities.<ref>{{Cite web|title=Using Cygwin effectively with Windows|url=https://www.cygwin.com/cygwin-ug-net/using-effectively.html#id325160}}</ref>

The Cygwin User's Guide has more information on this topic.<ref name="cygwin"/> [[MSYS2]], which is based on Cygwin, has a similar set of {{tt|winsymlinks}} settings but defaults to copying the files.<ref name=msys2-sym>{{cite web|url=https://github.com/msys2/MSYS2-packages/issues/249 |title=Coreutils: ln --symbolic creates hard links (MSYS2-packages #249)| website=GitHub}}</ref>

==Comparison of POSIX and Windows symbolic links==
{| class="wikitable plainrowheaders" style="text-align:center"
!  
! Symbolic link
! [[NTFS junction point|Junction]]
! [[Hard link]]
|-
! scope="row" | When the link is deleted...
| The target remains unchanged
| The target is deleted{{efn|except when using special tools}}
| A reference counter is decremented. When it reaches 0, the target is deleted.
|-
! scope="row" | When target is moved...
| The link becomes invalid
| The link becomes invalid
| The link remains valid
|-
! scope="row" | Relative path
| {{yes|Allowed}}
| {{No|Not allowed}}{{efn|On saving, becomes an absolute path}}
| {{N/A}}
|-
! scope="row" | Can be on a different volume?
| {{yes}}
| {{yes}}
| {{No}}
|-
! scope="row" | Link to files on [[Windows]]
| rowspan="2" {{yes}}{{Efn|Supported on Windows Vista and later. The Windows implementation is not POSIX-compliant. Creating them requires the "create symbolic link" privilege (SeCreateSymbolicLinkPrivilege). By default a user account holds this privilege when it is either an administrator or has Developer Mode enabled (Windows 10 v1703 and later).<ref>{{cite web |title=Create symbolic links |url=https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/create-symbolic-links |website=Windows client documentation for IT Pros |publisher=[[Microsoft]] |via=Microsoft Learn |date=18 January 2023}}</ref>}}
| {{No}}
| {{yes}}
|-
! scope="row" | Link to folders on [[Windows]]
| {{yes}}
| {{No}}
|-
! scope="row" | Link to files on [[Unix]]
| {{yes}}
| {{N/A}}
| {{yes}}
|-
! scope="row" | Link to folders on [[Unix]]
| {{yes}}
| {{N/A}}
| {{partial}}{{efn|POSIX permits hard links on folders but does not require them. Modern file systems tend to not support it.}}
|}
{{notelist}}

==Other implementations==
Implementations of features similar to symbolic links.

===Early MIT===

[[MIT]] [[Compatible Time-Sharing System]] {{circa|1963}} and [[Incompatible Timesharing System]] both have linked files where the name of the target file is specified in a directory entry.<ref name="50th"/><ref name="ctsspg69"/><ref name="ctsspg63"/>

===Data General RDOS===

[[Data General]]'s [[Data General RDOS|RDOS]] for its [[Data General Nova|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.<ref>{{cite book |url=http://www.bitsavers.org/pdf/dg/software/rdos/093-000075-08_RDOS_Reference_Manual_Mar79.pdf |title=Real Time Disk Operating System (RDOS) Reference Manual |pages=2{{hyp}}11-2{{hyp}}12 |publisher=[[Data General]] |date=March 1979}}</ref>

===Amiga===
The command creating symbolic links is <code>makelink</code>, 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.

===Mac OS===
{{Main|Alias (Mac OS)}}
In Mac OS, applications or users can also employ ''[[Alias (Mac OS)|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 (command)|alias]].

===OS/2===
In the [[OS/2]] operating system, symbolic links somewhat resemble [[Shadow (OS/2)|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.<ref>{{cite news |last1=Rojas |first1=Miguel |title=Cómo ejecutar versiones de Python diferentes a las predeterminadas |url=https://manualestutor.com/desarrollador-de-ios/como-ejecutar-versiones-de-python-diferentes-a-las-predeterminadas/ |newspaper=Manualestutor |date=16 December 2020 |access-date=20 December 2020}}</ref>

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

[[Operating system]]s that make use of variant symbolic links include [[NetBSD]], [[DragonFly BSD]], [[Domain/OS]].<ref>{{Man|7|symlink|NetBSD}}: magic symlinks.</ref><ref>{{cite web|url=https://wiki.freebsd.org/200808DevSummit?action=AttachFile&do=get&target=variant-symlinks-for-freebsd.pdf |title=Variant symbolic links for FreeBSD |date=2008 |author=Brooks Davis}}</ref><ref name=":0" />
[[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 (Unix)|universe]] a program was running in.  The universes supported were AT&Ts's [[UNIX System V|SysV.3]] and the [[Berkeley Software Distribution]] (BSD 4.3). For example: if the [[ps (Unix)|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''.<ref>{{cite web|date=2016|website=LWN|title=A case for variant symlinks|url=https://lwn.net/Articles/680705/|author=Neil Brown}}</ref>

==See also==
* [[Symlink race]] &mdash; a security-vulnerability caused by symbolic links
* [[freedup]] &mdash; generates links between identical data automatically
* [[Pointer (computer programming)]]

==References==
{{Reflist|2}}

==External links==
{{Wikibooks|Linux commands}}
* [https://linuxgazette.net/105/pitcher.html Q & A: The difference between hard and soft links] as applied to Linux
* [https://technet.microsoft.com/en-us/sysinternals/bb896768 Junction]: maintain NTFS junction points (for Windows 2000 and above)
* [https://technet.microsoft.com/en-us/library/cc788097%28WS.10%29.aspx FSUtil Hardlink]: Microsoft Technet page on using the command-line tool FSUtil to create hardlinks (for Windows 2000 and above)
* [https://emk.name/symlink.html Symbolic Drivers for Windows XP] {{in lang|ja}}: file system drivers to enable Symbolic Links for Windows XP (also mirrored on Link Shell Extension site). Sources available.

{{Computer files}}
{{File systems}}

[[Category:Computer file systems]]
[[Category:Unix file system technology]]