Symbolic link: Difference between revisions
Jump to navigation
Jump to search
imported>Guy Harris →Data General RDOS: Wrong heading level. |
imported>Guy Harris →Use: Those are APIs, not commands. (The chown *command* has a flag to control whether to follow symlinks or not, on systems with lchown().) |
||
| Line 2: | Line 2: | ||
{{for|the Microsoft data exchange format|Symbolic Link (SYLK)}} | {{for|the Microsoft data exchange format|Symbolic Link (SYLK)}} | ||
In [[computing]], a '''symbolic link''' ( | In [[computing]], a '''symbolic link''' (a.k.a. '''symlink''' or '''soft link''') is a special [[computer file]] that refers to another file or [[Directory (computing)|directory]] by storing a [[Path (computing)|path]] to it,<ref>{{cite web |url=https://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11 |title=Pathname resolution |work=[[POSIX]]}}</ref> 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 | 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 link]]s, [[Shortcut (computing)|shortcut files]], and [[Windows shell]] objects. | ||
==Overview== | == Overview == | ||
A symbolic link | 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 (computing)|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 | Symbolic links were introduced in 1982 in [[History of the Berkeley Software Distribution#4.2BSD|4.1a BSD Unix]].<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 [[POSIX]] standard defines the symbolic link as found in most [[Unix-like]] [[operating system]]s, such as [[FreeBSD]], [[Linux]], and [[macOS]]. [[Compatible Time-Sharing System#File system |CTSS]] on [[IBM 7090]] supported 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, some symbolic links were supported in minicomputer operating systems from [[Digital Equipment Corporation|DEC]],{{cn|date=September 2025}} and Data General's [[Data General RDOS|RDOS]]. | ||
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'' has a variable name (such as username of environment specific info) 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.<ref>{{Man|7|symlink|NetBSD}}: magic symlinks.</ref><ref>{{cite web |author=Brooks Davis |date=2008 |title=Variant symbolic links for FreeBSD |url=https://wiki.freebsd.org/200808DevSummit?action=AttachFile&do=get&target=variant-symlinks-for-freebsd.pdf}}</ref><ref name=":0">{{cite conference |last=Pike |first=Rob |author-link=Rob Pike |year=2000 |title=Lexical file names in Plan 9 or getting dot-dot right |url=https://static.usenix.org/events/usenix2000/general/full_papers/pikelex/pikelex.pdf |conference=Proc. [[USENIX]] Annual Tech. Conf.}}</ref> [[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''.<ref>{{cite web |author=Neil Brown |date=2016 |title=A case for variant symlinks |url=https://lwn.net/Articles/680705/ |website=LWN}}</ref> | ||
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 (graph theory)|tree]], which can affect otherwise simple operations. For example, navigating to a directory's parent may not work reliably with symbolic links. Some [[Unix shell]]s [[heuristic]]ally 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.<ref name=":0" /> | |||
[[Windows 95]] also had a similar intuitiveness concern, but instead of adopting symbolic links, created the [[Windows shell]], [[special folder]]s, and shortcut files (see {{Section link||Alternatives}} for details). | |||
==Unix-like== | |||
===Use=== | |||
In a [[Unix-like OS]], the <code>[[ln (Unix)|ln]]</code> [[Unix shell|shell command]] can create either a hard link (via the {{code|link()}} [[API]] function )<ref>{{man|3|link}}</ref> or a symbolic link (via the <code>symlink()</code> function).<ref>{{man|3|symlink}}</ref> The command's syntax for creating a symbolic link is as follows: | |||
<syntaxhighlight lang="console"> | <syntaxhighlight lang="console"> | ||
ln -s "<target's path>" "<link's path>" | |||
</syntaxhighlight> | |||
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". | |||
<syntaxhighlight lang="console"> | |||
$ touch foo | |||
$ ln -s foo bar | |||
$ | |||
$ | |||
</syntaxhighlight> | </syntaxhighlight> | ||
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 <code>lstat()</code>,<ref>{{man|3|lstat}}</ref> <code>lchown()</code><ref>{{man|3|lchown}}</ref> and <code>readlink()</code><ref>{{man|3|readlink}}</ref> APIs apply directly to link file; not their targets. An app (e.g., <code>[[ls]]</code> or <code>[[find (Unix)|find]]</code>) can use <code>lstat()</code> rather than <code>[[stat (system call)|stat()]]</code> to distinguish and report on symbolic links instead of their targets. Because the <code>rename()</code> and <code>[[unlink (Unix)|unlink()]]</code> API functions are coded to operate on symbolic links, the <code>[[rm (Unix)|rm]]</code> and <code>[[mv (Unix)|mv]]</code> commands (which use these APIs) affect the symbolic link itself. The <code>[[cp (Unix)|cp]]</code> command has options that allow either the symbolic link or the target to be copied. | |||
The <code>ls -l</code> command can reveal a symbolic link's target. The output shows the link's name, followed by a <code>-></code> mark and the link's target. In this example, <code>ls</code> reveals the symbolic link that the previous example created. | |||
<syntaxhighlight lang="console"> | |||
$ ls -l bar | |||
lrwxrwxrwx 1 user group 3 Aug 4 18:40 bar -> foo | |||
</syntaxhighlight> | |||
===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. ([[FreeBSD]], [[NetBSD]], [[DragonFly BSD]], and [[macOS]] can modify file permissions and [[file attribute]]s of a symbolic link, through <code>lchmod()</code><ref>{{man|2|lchmod|FreeBSD}}</ref><ref>{{man|2|lchmod|NetBSD}}</ref><ref>{{man|2|lchmod|DragonFly BSD}}</ref><ref>{{man|3|lchmod|Darwin}}</ref> and <code>lchflags()</code><ref>{{man|2|lchflags|FreeBSD}}</ref><ref>{{man|2|lchflags|NetBSD}}</ref><ref>{{man|2|lchflags|DragonFly BSD}}</ref><ref>{{man|3|lchflags|Darwin}}</ref> APIs respectively.) | |||
To enhance storage space and performance, the ''fast symlink'' allowed storage of the target path within the [[data structure]]s used for storing file information on disk ([[inode]]s). This space stores a list of disk [[Block (data storage)|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 [[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 symbolic links. | |||
==Windows== | |||
{{Expand section|with=information about ReFS|small=no|date=November 2025}} | |||
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 === | ||
{{Main|NTFS junction point|NTFS volume mount point}} | |||
Starting with Windows 2000, NTFS supports junction points,<ref>{{Cite web |last=Russinovich |first=Mark |author-link=Mark Russinovich |date=4 July 2016 |title=Junction |url=https://learn.microsoft.com/en-us/sysinternals/downloads/junction |website=Sysinternals |publisher=[[Microsoft]] |via=[[Microsoft Learn]]}}</ref> also known as soft links.<ref name=":3">{{Cite web |last=Ashcraft |first=Alvin |date=8 July 2025 |title=Hard Links and Junctions |url=https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions |access-date=2025-09-30 |website=Windows App Development |publisher=[[Microsoft]] |via=[[Microsoft Learn]]}}</ref> Junction points are similar to symbolic links, but only link to other directories, not files. They are implemented via [[NTFS reparse point]]s.<ref name=":3" /> Windows 7 and Vista support a maximum of 31 reparse points for a given path (i.e. any given path can have at most 31 redirections before Windows gives up).<ref>{{cite web |url=https://learn.microsoft.com/en-us/windows/win32/fileio/symbolic-link-programming-considerations |title=Programming Considerations (Local File Systems) |website=[[Microsoft Learn]]}}</ref> | |||
Also starting with 2000, NTFS supports volume mount points. Normally, Windows [[Volume (computing)|volumes]] are [[Drive letter assignment|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=== | ===NTFS symbolic link=== | ||
{{Main|NTFS symbolic link}} | {{Main|NTFS symbolic link}} | ||
[[NTFS]] 3.1 introduced support for symbolic links | [[NTFS]] version 3.1 introduced support for symbolic links. [[Windows XP]] partially implemented NTFS 3.1, leaving out symbolic links. Thus, a third-party driver ise 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> [[Windows Vista]] and later enabled support for symbolic links.<ref name=":1" /> Unlike [[NTFS 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-[[Volume (computing)|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".<ref | 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 name=":1">{{cite web |date=8 July 2025 |title=Symbolic Links |url=https://learn.microsoft.com/en-us/windows/win32/fileio/symbolic-links |website=Windows App Development |publisher=[[Microsoft]] |via=[[Microsoft Learn]]}}</ref> To create a symbolic link, the user account must possess the new ''"''Create Symbolic Link" privilege (<code>SeCreateSymbolicLinkPrivilege</code>), which, by default, only admins have.<ref>{{cite web |first=Mark |last=Russinovich |author-link=Mark Russinovich |url=https://learn.microsoft.com/en-us/previous-versions/technet-magazine/cc162494(v=msdn.10) |title=Inside the Windows Vista Kernel: Part 1 |at=File-based symbolic links |website=[[Microsoft Learn]] |date=February 2007}}</ref> 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. | ||
Users could use [[Command Prompt]] or [[PowerShell]] to create symbolic links. The following creates a symbolic link called "Downloads" at "<code>E:\</code>" that points to the Downloads folder in the user's profile. This works in Command Prompt only as <code>mklink</code> is a built-in shell command. | |||
<syntaxhighlight lang="batch"> | |||
mklink /D E:\Downloads %UserProfile%\Downloads | mklink /D E:\Downloads %UserProfile%\Downloads | ||
</syntaxhighlight> | </syntaxhighlight> | ||
The <code>/D</code> 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: | |||
The | |||
<syntaxhighlight lang="ps1"> | |||
New-Item -Path 'E:\Downloads' -ItemType 'SymbolicLink' -Value "$Env:UserProfile\Downloads" | |||
</syntaxhighlight>Unlike Command Prompt, PowerShell returns an error if the source object path is invalid. In exchange, PowerShell correctly determines the type of the source object and creates the right type of symbolic link. | |||
In addition to file and folders, NTFS symbolic links can point to an [[alternate data stream]]. The following example creates a symbolic link called "<code>Test.txt</code>" that points the "<code>Zone.Identifier:$DATA</code>" alternative stream of a file called "<code>npcap-1.83.exe</code>". (This particular alternative stream is the [[Mark of the Web|mark of the web]].)<syntaxhighlight lang="powershell"> | |||
New-Item -Path "E:\Test.txt" -ItemType 'SymbolicLink' -Value 'E:\npcap-1.83.exe:Zone.Identifier:$DATA' | |||
</syntaxhighlight>The low-function responsible for creating symbolic links is the <code>CreateSymbolicLink()</code> function of [[Windows API]], introduced in 2008. It can create both file and directory symbolic links.<ref>{{Cite web |last=Walker |first=Jim |date=1 June 2024 |title=CreateSymbolicLinkW function (winbase.h) |url=https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createsymboliclinkw |website=Windows App Development}}</ref> Much later, in 2021, Microsoft introduced <code>File.CreateSymbolicLink()</code> and <code>Directory.CreateSymbolicLink()</code> methods to [[.NET|.NET 6]]. They are free and open-source.<ref>{{Cite web |last=Warren |first=Genevieve |title=File.CreateSymbolicLink(String, String) Method (System.IO) |url=https://learn.microsoft.com/en-us/dotnet/api/system.io.file.createsymboliclink?view=net-9.0 |access-date=2025-09-30 |website=.NET 6 Documentation |publisher=[[Microsoft]] |via=[[Microsoft Learn]]}}</ref><ref>{{Cite web |last=Warren |first=Genevieve |title=Directory.CreateSymbolicLink(String, String) Method (System.IO) |url=https://learn.microsoft.com/en-us/dotnet/api/system.io.directory.createsymboliclink?view=net-9.0 |access-date=2025-09-30 |website=.NET 6 Documentation |publisher=[[Microsoft]] |via=[[Microsoft Learn]]}}</ref> | |||
=== | ===Kernel symbolic links=== | ||
{{Missing information|Kernel symbolic links, i.e., links from the Win32 namespace (<code>\\GLOBAL??</code>) to NT namespace|date=September 2025}} | |||
< | |||
===Cygwin symbolic links=== | ===Cygwin symbolic links=== | ||
[[Cygwin]] simulates POSIX- | [[Cygwin]] simulates POSIX-conforming symbolic links in the 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 symbolic link resolution. Cygwin symbolic links comply 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: | 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: | ||
| Line 171: | Line 100: | ||
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> | 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 | ==Comparison of symbolic link implementations== | ||
The following table compares various aspects of the symbolic link (both UNIX-based and Windows), junction point (NTFS) and hard link (UNIX-based). | |||
{| class="wikitable plainrowheaders" style="text-align:center" | {| class="wikitable plainrowheaders" style="text-align:center" | ||
! | ! | ||
! Symbolic link | ! Symbolic link | ||
! | ! Junction point | ||
! | ! Hard link | ||
|- | |- | ||
! scope="row" | | ! scope="row" | Target is deleted when link is deleted? | ||
| | | {{no}} | ||
| | | {{yes}}{{efn|except when using special tools}} | ||
| | | Only if the reference count<br> is 0 after decrementing | ||
|- | |- | ||
! scope="row" | | ! scope="row" | Link is valid if target is moved? | ||
| | | {{no}} | ||
| | | {{no}} | ||
| | | {{yes}} | ||
|- | |- | ||
! scope="row" | Relative path | ! scope="row" | Relative path allowed? | ||
| {{yes | | {{yes}} | ||
| {{No | | {{No}}{{efn|On saving, becomes an absolute path}} | ||
| {{N/A}} | | {{N/A}} | ||
|- | |- | ||
! scope="row" | Can | ! scope="row" | Can link to different volume? | ||
| {{yes}} | | {{yes}} | ||
| {{yes}} | | {{yes}} | ||
| {{No}} | | {{No}} | ||
|- | |- | ||
! scope="row" | | ! scope="row" | Can link to file? | ||
| rowspan="2" {{yes}}{{Efn|Supported on Windows Vista and later. The Windows implementation is not POSIX- | | rowspan="2" {{yes}}{{Efn|Supported on Windows Vista and later. The Windows implementation is not POSIX-conforming. Creating them requires the "create symbolic link" privilege (<code>SeCreateSymbolicLinkPrivilege</code>). By default a user account holds this privilege when it is either an administrator<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> or has Developer Mode enabled (Windows 10 v1703 and later).<ref>{{Cite web |last=Durr |first=Yosef |url=https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/ |title=Symlinks in Windows 10! |website=Windows Experience |via=Windows Blogs |publisher=Microsoft |date=2 December 2016}}</ref>}} | ||
| {{No}} | | {{No}} | ||
| {{yes}} | | {{yes}} | ||
|- | |- | ||
! scope="row" | | ! scope="row" | Can link to directory? | ||
| {{yes}} | | {{yes}} | ||
| {{partial}}{{efn |POSIX permits a hard link to a directory but does not require the capability. Modern file systems tend to not support it.}} | |||
| {{partial}}{{efn|POSIX permits hard | |||
|} | |} | ||
{{notelist}} | {{notelist}} | ||
| Line 233: | Line 154: | ||
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. | 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=== | ===Classic Mac OS=== | ||
{{Main|Alias (Mac OS)}} | {{Main|Alias (Mac OS)}} | ||
In Mac OS, applications or users can | In the [[classic Mac OS]], applications or users can use ''[[Alias (Mac OS)|aliases]]'', which, unlike symbolic links, follow 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]] on several shells for Unix-like systems.) | ||
[[macOS]] also supports aliases; they are not supported by Unix [[API]]s such as <code>[[open (system call)|open()]]</code>, but are supported by [[Carbon (API)|Carbon]] and [[Cocoa (API)|Cocoa]] higher-level APIs. | |||
===OS/2=== | ===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> | 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> | ||
== | == Alternatives == | ||
===File shortcuts=== | |||
[[Shortcut (computing)|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: | ||
[[ | * 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 symbolic link 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). | ||
* 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 |date=23 February 2023 |title=Distributed Link Tracking on domain controllers - Windows Server |url=https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/distributed-link-tracking-on-domain-controller}}</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 |date=30 December 2021 |title=Distributed Link Tracking and Object Identifiers |url=https://learn.microsoft.com/en-us/windows/win32/fileio/distributed-link-tracking-and-object-identifiers |access-date=1 September 2025 |website=[[Microsoft Learn]] |publisher=Microsoft Corporation}}</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 === | ||
The [[Windows shell]] allows ordinary directories on file systems to act as "junction points".<ref name=":2">{{cite web |date=6 January 2021 |title=Specifying a Namespace Extension's Location |url=https://learn.microsoft.com/en-us/windows/win32/shell/nse-junction#using-file-system-folders-as-junction-points |website=Windows Shell Library |publisher=[[Microsoft]] |at=Using File System Folders as Junction Points |via=[[Microsoft Learn]]}}</ref> They are transparent to the Windows shell, but useless in other environments. Windows offers two methods to implement a folder shortcut. The first is through a special naming convention. The folder shortcut must be adhere to the following syntax: <code>Name.{CLSID}</code>.<ref name=":2" /> Windows shell will replace the entire name with the associated CLSID's display name. For example, <code>Test.{B4BFCC3A-DB2C-424C-B029-7FE99A87C641}</code> becomes a shortcut Windows Desktop. | |||
The second requires the following:<ref name=":2" /> | |||
* Adding the "Read-Only" [[File attribute|attribute]] to the folder.<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/en-us/help/326549/you-cannot-view-or-change-the-read-only-or-the-system-attributes-of-fo |url-status=dead |archive-url=https://web.archive.org/web/20171117145105/https://support.microsoft.com/en-us/help/326549/you-cannot-view-or-change-the-read-only-or-the-system-attributes-of-fo |archive-date=17 November 2017 |website=support.microsoft.com}}</ref> | |||
* Making the folder a system folder by calling the <code>PathMakeSystemFolder()</code> function. | |||
* Placing a hidden <code>Desktop.ini</code> file in the folder. An example of <code>Desktop.ini</code> is as follows: | |||
<syntaxhighlight lang="ini"> | |||
[.ShellClassInfo] | |||
CLSID2={0AFACED1-E828-11D1-9187-B532F1E9575D} | |||
</syntaxhighlight> | |||
===Shell objects in Windows shell=== | |||
The ''shell objects''<ref>{{cite web |date=29 June 2010 |title=Creating Shell Extensions with Shell Instance Objects |url=https://learn.microsoft.com/en-us/previous-versions/ms997573(v=msdn.10) |website=[[Microsoft Learn]]}}</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. | |||
The following is a general template. <code>{########-####-####-####-############}</code>, <code>0x####</code>, and <code><Path></code> are placeholders. | |||
<syntaxhighlight lang="registry"> | |||
[HKEY_CLASSES_ROOT\CLSID\{########-####-####-####-############}] | |||
@="display name" | |||
[HKEY_CLASSES_ROOT\CLSID\{########-####-####-####-############}\DefaultIcon] | |||
@="..." ; path to icon | |||
[HKEY_CLASSES_ROOT\CLSID\{########-####-####-####-############}\InProcServer32] | |||
@="%SystemRoot%\\System32\\ShDocVw.Dll" | |||
"ThreadingModel"="Apartment" | |||
[HKEY_CLASSES_ROOT\CLSID\{########-####-####-####-############}\Instance] | |||
"CLSID"="{0AFACED1-E828-11D1-9187-B532F1E9575D}" | |||
[HKEY_CLASSES_ROOT\CLSID\{########-####-####-####-############}\Instance\InitPropertyBag] | |||
"Attributes"=hex:15,00,00,00 | |||
; You can specify one of the following: | |||
; | |||
; - "Target" with an absolute file system path. | |||
; - "Target" with a relative path, if "TargetKnownFolder" or "TargetSpecialFolder" are also specified. | |||
; - "TargetSpecialFolder" (with or without a "Target" containing a relative path). | |||
; Should contain the CSIDL of the target. | |||
; - "TargetKnownFolder" (with or without a "Target" containing a relative path). | |||
; Should contain the GUID of the target. | |||
; Supported on Windows Vista and later. | |||
"Target"="<Path>" | |||
"TargetSpecialFolder"="0x####" | |||
"TargetKnownFolder"="{########-####-####-####-############}" | |||
[HKEY_CLASSES_ROOT\CLSID\{########-####-####-####-############}\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. | |||
==See also== | ==See also== | ||
| Line 256: | Line 236: | ||
==References== | ==References== | ||
{{Reflist | {{Reflist}} | ||
==External links== | ==External links== | ||
Latest revision as of 20:50, 7 November 2025
Template:Short description Script error: No such module "For".
In computing, a symbolic link (a.k.a. symlink or soft link) is a special computer file that refers to another file or directory by storing a path to it,[1] 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.[2] 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.[3][4][5] By 1978, some symbolic links were supported in minicomputer operating systems from DEC,Script error: No such module "Unsubst". 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 (such as username of environment specific info) 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.[6][7][8] 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.[9]
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.[8]
Windows 95 also had a similar intuitiveness concern, but instead of adopting symbolic links, created the Windows shell, special folders, and shortcut files (see Template:Section link for details).
Unix-like
Use
In a Unix-like OS, the ln shell command can create either a hard link (via the link() API function )[10] or a symbolic link (via the symlink() function).[11] The command's syntax for creating a symbolic link is as follows:
ln -s "<target's path>" "<link's path>"
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(),[12] lchown()[13] and readlink()[14] APIs apply directly to link file; not their targets. An app (e.g., ls or find) 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 (which use these APIs) 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. (FreeBSD, NetBSD, DragonFly BSD, and macOS can modify file permissions and file attributes of a symbolic link, through lchmod()[15][16][17][18] and lchflags()[19][20][21][22] 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 (inodes). 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
Script error: No such module "Unsubst".
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
Script error: No such module "Labelled list hatnote". Starting with Windows 2000, NTFS supports junction points,[23] also known as soft links.[24] Junction points are similar to symbolic links, but only link to other directories, not files. They are implemented via NTFS reparse points.[24] Windows 7 and Vista support a maximum of 31 reparse points for a given path (i.e. any given path can have at most 31 redirections before Windows gives up).[25]
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
Script error: No such module "Labelled list hatnote". NTFS version 3.1 introduced support for symbolic links. Windows XP partially implemented NTFS 3.1, leaving out symbolic links. Thus, a third-party driver ise required to enable support for NTFS symbolic links in Windows XP.[26] Windows Vista and later enabled support for symbolic links.[27] Unlike NTFS 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-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".[27] To create a symbolic link, the user account must possess the new "Create Symbolic Link" privilege (SeCreateSymbolicLinkPrivilege), which, by default, only admins have.[28] 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"
Unlike Command Prompt, PowerShell returns an error if the source object path is invalid. In exchange, PowerShell correctly determines the type of the source object and creates the right type of symbolic link.
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". (This particular alternative stream is the mark of the web.)
New-Item -Path "E:\Test.txt" -ItemType 'SymbolicLink' -Value 'E:\npcap-1.83.exe:Zone.Identifier:$DATA'
The low-function responsible for creating symbolic links is the CreateSymbolicLink() function of Windows API, introduced in 2008. It can create both file and directory symbolic links.[29] Much later, in 2021, Microsoft introduced File.CreateSymbolicLink() and Directory.CreateSymbolicLink() methods to .NET 6. They are free and open-source.[30][31]
Kernel symbolic links
Cygwin symbolic links
Cygwin simulates POSIX-conforming symbolic links in the 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 symbolic link resolution. Cygwin symbolic links comply 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.[32] This requires:
- Changing the CYGWIN environment variable to contain Template:Tt;
- 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 ln -s command. To create standard Microsoft .lnk files Cygwin provides the mkshortcut and readshortcut utilities.[33]
The Cygwin User's Guide has more information on this topic.[32] MSYS2, which is based on Cygwin, has a similar set of Template:Tt settings but defaults to copying the files.[34]
Comparison of symbolic link implementations
The following table compares various aspects of the symbolic link (both UNIX-based and Windows), junction point (NTFS) and hard link (UNIX-based).
| Symbolic link | Junction point | Hard link | |
|---|---|---|---|
| Target is deleted when link is deleted? | No | YesTemplate:Efn | Only if the reference count is 0 after decrementing |
| Link is valid if target is moved? | No | No | Yes |
| Relative path allowed? | Yes | NoTemplate:Efn | Template:N/A |
| Can link to different volume? | Yes | Yes | No |
| Can link to file? | YesTemplate:Efn | No | Yes |
| Can link to directory? | Yes | PartialTemplate:Efn |
Other implementations
Implementations of features similar to symbolic links.
Early MIT
MIT Compatible Time-Sharing System Template:Circa and Incompatible Timesharing System both have linked files where the name of the target file is specified in a directory entry.[3][4][5]
Data General RDOS
Data General's RDOS for its 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.[35]
Amiga
The command creating symbolic links is makelink, 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.
Classic Mac OS
Script error: No such module "Labelled list hatnote". In the classic Mac OS, applications or users can use aliases, which, unlike symbolic links, follow 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 on several shells for Unix-like systems.)
macOS also supports aliases; they are not supported by Unix APIs such as open(), but are supported by Carbon and Cocoa higher-level APIs.
OS/2
In the OS/2 operating system, symbolic links somewhat resemble 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.[36]
Alternatives
File shortcuts
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:
- 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 symbolic link 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).
- 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[37] 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.[38] Additionally, in Windows 9x and later, Windows shell tries to find the target of a broken shortcut before proposing to delete it.
Folder shortcuts
The Windows shell allows ordinary directories on file systems to act as "junction points".[39] They are transparent to the Windows shell, but useless in other environments. Windows offers two methods to implement a folder shortcut. The first is through a special naming convention. The folder shortcut must be adhere to the following syntax: Name.{CLSID}.[39] Windows shell will replace the entire name with the associated CLSID's display name. For example, Test.{B4BFCC3A-DB2C-424C-B029-7FE99A87C641} becomes a shortcut Windows Desktop.
The second requires the following:[39]
- Adding the "Read-Only" attribute to the folder.[40]
- Making the folder a system folder by calling the
PathMakeSystemFolder()function. - Placing a hidden
Desktop.inifile in the folder. An example ofDesktop.iniis as follows:
[.ShellClassInfo]
CLSID2={0AFACED1-E828-11D1-9187-B532F1E9575D}
Shell objects in Windows shell
The shell objects[41] 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.
The following is a general template. {########-####-####-####-############}, 0x####, and <Path> are placeholders.
[HKEY_CLASSES_ROOT\CLSID\{########-####-####-####-############}]
@="display name"
[HKEY_CLASSES_ROOT\CLSID\{########-####-####-####-############}\DefaultIcon]
@="..." ; path to icon
[HKEY_CLASSES_ROOT\CLSID\{########-####-####-####-############}\InProcServer32]
@="%SystemRoot%\\System32\\ShDocVw.Dll"
"ThreadingModel"="Apartment"
[HKEY_CLASSES_ROOT\CLSID\{########-####-####-####-############}\Instance]
"CLSID"="{0AFACED1-E828-11D1-9187-B532F1E9575D}"
[HKEY_CLASSES_ROOT\CLSID\{########-####-####-####-############}\Instance\InitPropertyBag]
"Attributes"=hex:15,00,00,00
; You can specify one of the following:
;
; - "Target" with an absolute file system path.
; - "Target" with a relative path, if "TargetKnownFolder" or "TargetSpecialFolder" are also specified.
; - "TargetSpecialFolder" (with or without a "Target" containing a relative path).
; Should contain the CSIDL of the target.
; - "TargetKnownFolder" (with or without a "Target" containing a relative path).
; Should contain the GUID of the target.
; Supported on Windows Vista and later.
"Target"="<Path>"
"TargetSpecialFolder"="0x####"
"TargetKnownFolder"="{########-####-####-####-############}"
[HKEY_CLASSES_ROOT\CLSID\{########-####-####-####-############}\ShellFolder]
"Attributes"=hex:00,00,00,00
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.
See also
- Symlink race — a security-vulnerability caused by symbolic links
- freedup — generates links between identical data automatically
- Pointer (computer programming)
References
External links
- Q & A: The difference between hard and soft links as applied to Linux
- Junction: maintain NTFS junction points (for Windows 2000 and above)
- FSUtil Hardlink: Microsoft Technet page on using the command-line tool FSUtil to create hardlinks (for Windows 2000 and above)
- Symbolic Drivers for Windows XP Template:In lang: file system drivers to enable Symbolic Links for Windows XP (also mirrored on Link Shell Extension site). Sources available.
Template:Computer files Template:File systems
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ a b Script error: No such module "citation/CS1".
- ↑ a b Script error: No such module "citation/CS1".
- ↑ a b Script error: No such module "citation/CS1".
- ↑ Template:Man: magic symlinks.
- ↑ Script error: No such module "citation/CS1".
- ↑ a b Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Template:Man
- ↑ Template:Man
- ↑ Template:Man
- ↑ Template:Man
- ↑ Template:Man
- ↑ Template:Man
- ↑ Template:Man
- ↑ Template:Man
- ↑ Template:Man
- ↑ Template:Man
- ↑ Template:Man
- ↑ Template:Man
- ↑ Template:Man
- ↑ Script error: No such module "citation/CS1".
- ↑ a b Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ a b Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ a b Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ a b c Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".