Editing Symbolic link (section)

==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>