NTFS links: Difference between revisions
m convert special characters found by Wikipedia:Typo Team/moss (via WP:JWB) |
Citation bot (talk | contribs) Added date. | Use this bot. Report bugs. | Suggested by Abductive | Category:Use American English from October 2024 | #UCB_Category 676/962 |
||
(25 intermediate revisions by 20 users not shown) | |||
Line 1: | Line 1: | ||
{{Short description|Abstractions used in the NTFS file system}} |
|||
{{redirect|Junction point|the video game studio|Junction Point Studios}} |
{{redirect|Junction point|the video game studio|Junction Point Studios}} |
||
{{Use mdy dates|date=October 2024}} |
|||
The [[NTFS]] file system defines various ways to redirect files and folders, e.g., to make a file point to another file or its contents. The object being pointed to is called the target. There are three classes of links: |
|||
{{Use American English|date=October 2024}} |
|||
* '''[[Hard link]]s''', which have files share the same MFT entry ([[inode]]), in the same filesystem. |
|||
* '''Junction points''', which are similar to hard links, but defined for folders. Only accepts local, absolute paths.<ref>{{cite web |title=Hard Links and Junctions |url=https://docs.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions |website=Windows Developer |publisher=[[Microsoft]] |date=31 May 2018}}</ref><ref name="junction.exe" /> |
|||
* '''[[Symbolic link]]s''', which record the path of another file that the links contents should show. Can accept relative paths. Support for directory and [[UNC path]]s were added in NTFS 3.1. |
|||
'''NTFS links''' are the [[abstraction (computer science)|abstraction]] used in the [[NTFS]] file system—the default file system for all [[Microsoft Windows]] versions belonging to the [[Windows NT family]]—to associate [[pathname]]s and certain kinds of [[metadata]], with entries in the NTFS [[Master File Table]] (MFT). NTFS broadly adopts a pattern akin to typical [[Unix file systems]] in the way it stores and references file data and metadata; the most significant difference is that in NTFS, the MFT "takes the place of" [[inodes]], fulfilling most of the functions which inodes fulfill in a typical Unix filesystem. |
|||
All NTFS links are designed to be transparent to applications. This means that the application accessing a link will be seamlessly redirected by the file system driver, and no special handling is needed. To users, they appear as normal directories or files. This also leads to an [[Aliasing (computing)|aliasing]] effect: writes to a link will pass the write to the underlying, linked file or MFT entry. |
|||
In NTFS, an entity in the filesystem fundamentally exists as: a record stored in the MFT of an NTFS volume, the MFT being the core [[database]] of the NTFS filesystem; and, any attributes and [[NTFS stream]]s associated with said record. A link in NTFS is ''itself'' a record, stored in the MFT, which "points" to ''another'' MFT record: the ''target'' of the link. Links are the file "entries" in the volume's hierarchical [[file tree]]: an NTFS [[pathname]] such as {{samp|\foo.exe}} or {{samp|\foobar\baz.txt}} '''is''' a link. If the volume containing said pathnames were mapped to {{samp|D:}} in a Windows system, these could be referenced as {{samp|D:\foo.exe}} and {{samp|D:\foobar\baz.txt}}. (Compare and contrast with typical Unix file systems, where a link is an entry in a directory—directories themselves being just a type of file stored in the filesystem—pointing either to another link, or to an inode.) |
|||
Symbolic links and junction points, which need to carry additional data including the path they point to, are based on [[NTFS reparse point]]s. Their path-recording nature means that they can link to files on other volumes or even remote files. On the other hand, hard links are created simply by giving an entry in the MFT a new filename to take on, so it is restricted to files in the same filesystem. |
|||
== Types of links == |
|||
An NTFS symbolic link is not the same as a [[File shortcut#Microsoft Windows|Windows shortcut file]], which is a regular file. The latter may be created on any filesystem (such as the earlier [[FAT32]]), may contain metadata (such as an icon to display when the shortcut is viewed in [[Windows Explorer]]), and is not transparent to applications. |
|||
NTFS has four types of links. These map relatively closely to the generic [[hard link]] and [[soft link]] concepts which modern file systems tend to follow. |
|||
== |
=== Hard links === |
||
'''[[Hard links]]''' are typical in behavior. A hard link "points" to an MFT record. That ''target'' record will be the record for a "regular" file, such as a [[text file]] or [[executable]] (assuming the NTFS volume is in a normal "healthy" state). Compare with a typical [[Unix file system]], where a hard link points to an [[inode]]. As in such file systems, an NTFS hard link cannot point to a directory. |
|||
Symbolic links to directories or volumes, called [[NTFS junction point|junction points]] and mount points, were introduced with NTFS 3.0 that shipped with Windows 2000. From NTFS 3.1 onwards, symbolic links can be created for any kind of file system object. NTFS 3.1 was introduced together with [[Windows XP]], but the functionality was not made available (through ntfs.sys) to user mode applications. Third-party filter drivers {{ndash}} such as Masatoshi Kimura's opensource <code>senable</code> driver {{ndash}} could however be installed to make the feature available in user mode as well. The ntfs.sys released with [[Windows Vista]] made the functionality available to user mode applications by default. |
|||
A typical new file creation event on an NTFS volume, then, simply involves NTFS allocating and creating one new MFT record, for storing the new file entity's file [[metadata]]—including, about any of the data clusters assigned to the file, and the file's data streams; one MFT record for a hard link which points to the first newly-created MFT record as its ''target''; storing a reference to the hard link in a directory file; and setting the [[reference count]] of both these MFT records to{{nbsp}}{{samp|1}}. Any [[file name]] provided as part of the file creation event is stored in the hard link. An MFT record can be the target of up to 1024 hard links; each time a new hard link is successfully created, targeting a previously extant MFT record, the target's reference count is incremented. |
|||
Since NTFS 3.1, a symbolic link can also point to a file or remote [[Server Message Block|SMB]] network path. While NTFS junction points support only absolute paths on local drives, the NTFS symbolic links allow linking using relative paths. Additionally, the NTFS symbolic link implementation provides full support for cross-filesystem links. However, the functionality enabling cross-host symbolic links requires that the remote system also support them, which effectively limits their support to Windows Vista and later Windows operating systems. |
|||
Symmetrically, the immediate tasks performed by NTFS in a typical [[file deletion]] event, when deleting a hard link, are simply: removing the reference to the link from the directory file containing it (the root directory, if applicable); and decrementing by{{nbsp}}{{samp|1}} the reference counts of the MFT record targeted by the link, and, of the entry containing the hard link ''itself''. Any MFT record which now has a refcount of {{nbsp}}{{samp|0}}, is now in the "deleted" state: all its associated resources are considered "free" by NTFS, to be freely overwritten and used as needed. |
|||
==Restrictions and drawbacks== |
|||
The default security settings in Windows Vista/[[Windows 7]] disallow non-elevated administrators and all non-administrators from creating symbolic links but not junctions. This behavior can be changed running "secpol.msc" the Local Security Policy management console (under: Security Settings\Local Policies\User Rights Assignment\Create symbolic links). It can be worked around by starting [[cmd.exe]] with ''Run as administrator'' option or the <code>[[runas]]</code> command. Starting with Windows 10 Insiders build 14972 the requirement for elevated administrator privileges was removed in Windows "Developer Mode", allowing symlinks to be created without needing to elevate the console as administrator. On the API level, a {{code|SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE}} flag is supplied for this purpose.<ref>{{cite web|url=https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/#Ed9Olhkz6hJp4KWV.97|title=Symlinks in Windows 10! - Windows Developer BlogWindows Developer Blog|website=blogs.windows.com|date=2 December 2016}}</ref> |
|||
=== |
=== Junction points === |
||
'''Junction points''' are [[NTFS reparse points]] and operate similarly to [[symbolic links]] in Unix or Linux, but are only defined for directories, and may only be absolute paths on local filesystems (as opposed to remote filesystems being accessed). They are created and behave in a similar way to hard links, except that if the target directory is renamed, moved, or deleted, the link will no longer be valid.<ref>{{cite web |date=31 May 2018 |title=Hard Links and Junctions |url=https://docs.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions |website=Windows Developer |publisher=[[Microsoft]]}}</ref><ref name="junction.exe" /> |
|||
Neither the [[Windows NT startup process]] nor the [[Windows Vista startup process]] support Junction points, so it is impossible to redirect certain system folders: |
|||
* \Windows |
|||
* \Windows\System32 |
|||
* \Windows\Config |
|||
=== Symbolic links === |
|||
However it is possible to redirect non-critical folders: |
|||
* \Users |
|||
'''[[Symbolic link]]s''' are [[NTFS reparse point|reparse points]] which operate similarly to Junction Points, or symbolic links in Unix or Linux, and accept relative paths and paths to files as well as directories. Support for directory and UNC paths were added in NTFS 3.1. |
|||
* \Documents and Settings |
|||
* \Program Files |
|||
* [[NTFS volume mount point]]s |
|||
* \Program Files (x86) |
|||
All NTFS links are intended to be transparent to applications. This means that the application accessing a link will be seamlessly redirected by the file system driver, and no special handling is needed. To users, they appear as normal directories or files. This also leads to an aliasing effect: writes to a link will pass the write to the underlying, linked file or [[Master File Table|MFT]] entry. |
|||
Symbolic links and junction points contain the path to the linked file, and a tag identifying the driver which implements the behaviour. Because they record the path, they can link to files on other volumes or even remote files. However this also means that if the referenced file is deleted or renamed, the link becomes invalid, and if the referenced file or directory is replaced with another, the link will now refer to the new file or directory. |
|||
Creating junctions for \Users and \ProgramData pointing to another drive is not recommended as it breaks updates and Windows Store Apps.<ref name="auto">{{Cite web|url = http://support.microsoft.com/kb/949977|title = Relocation of the Users directory and the ProgramData directory to a drive other than the drive that contains the Windows directory|access-date = 2015-03-12}}</ref> |
|||
===Shortcut files=== |
|||
Creating junctions for \Users, \ProgramData, "\Program Files" or "\Program Files (x86)" pointing to other locations breaks installation or upgrade of Windows.<ref name="auto1">{{Cite web|url = http://support.microsoft.com/kb/2876597|title = You encounter an error when trying to install Windows 8.1 due to redirecting the Users or Program Files folder to another partition|access-date = 2015-03-12}}</ref> |
|||
An NTFS symbolic link is not the same as a [[Windows shortcut file]], which is a regular file. The latter may be created on any filesystem (such as the earlier [[FAT32]]), may contain metadata (such as an icon to display when the shortcut is viewed in Remove links), and is not transparent to applications. |
|||
Implementations of unix-like environments for Windows such as [[Cygwin]] and [[Mingw]] can use shortcut files to emulate symbolic links where the host operating system does not support them, if configured to do so. |
|||
Creating junctions for "\Program Files" or "\Program Files (x86)" pointing to another drive breaks Windows' [[Management features new to Windows Vista#Component Based Servicing|Component Based Servicing]] which hardlinks files from its repository \Windows\SxS to their installation directory.{{cn|date=September 2017}} |
|||
==Examples of use== |
==Examples of use== |
||
Line 41: | Line 40: | ||
===Built-in uses=== |
===Built-in uses=== |
||
* Windows Component Store ([[WinSxS]]) use hard links to keep track of different versions of [[dynamic-link library|DLLs]] stored on the hard disk drive. |
* Windows Component Store ([[WinSxS]]) use hard links to keep track of different versions of [[dynamic-link library|DLLs]] stored on the hard disk drive. |
||
* |
* Basic installations of [[Windows Server 2008]] used symlinks for \Users\All Users\ → \ProgramData\ redirection. |
||
* Since [[Windows Vista]], all versions of Windows have used a specific scheme of built-in directories and utilize hidden junctions to maintain [[backward compatibility]] with Windows XP and older. Examples of these junctions are: |
|||
** <code>C:\Documents and Settings</code> pointing to <code>C:\Users</code> |
|||
** <code>%USERPROFILE%\Application Data</code> pointing to <code>%USERPROFILE%\AppData\Roaming</code> |
|||
** <code>%USERPROFILE%\My Documents\My Pictures</code> pointing to <code>%USERPROFILE%\Pictures</code> |
|||
===Program redirection=== |
===Program redirection=== |
||
By setting a junction point that points to a directory containing a particular version of a piece of software, it may be possible to add another version of the software and redirect the junction point to point to the version desired. |
By setting a junction point that points to a directory containing a particular version of a piece of software, it may be possible to add another version of the software and redirect the junction point to point to the version desired. |
||
===Saving |
===Saving storage space=== |
||
The contents of a junction use almost no |
The contents of a junction use almost no storage space (they simply point to the original directory). If an administrator needs to have multiple points of entry to a large directory, junction points can be an effective solution. Junction points should not be confused with a ''copy'' of something as junctions simply point to the original. If directories need to be modified separately a junction cannot be used as it does not provide a distinct copy of the directory or files within. |
||
Likewise, symbolic links and hard links are useful for merging the contents of individual files. |
Likewise, symbolic links and hard links are useful for merging the contents of individual files. |
||
===Circumventing predefined paths=== |
===Circumventing predefined paths=== |
||
Since reinstalling Windows (or installing a new version) often requires deleting the contents of the C: drive, it is advantageous to create multiple [[Disk partitioning|partition]]s so only one partition needs to be deleted during the installation. However, some programs don't let the user choose the installation directory, or install some of their files to the C: drive even when they are installed to a different drive. By creating a junction point, the program can be tricked into installing to a different directory. |
Since reinstalling Windows (or installing a new version) often requires deleting the contents of the <code>C:</code> drive, it is advantageous to create multiple [[Disk partitioning|partition]]s so only one partition needs to be deleted during the installation. However, some programs don't let the user choose the installation directory, or install some of their files to the <code>C:</code> drive even when they are installed to a different drive. By creating a junction point, the program can be tricked into installing to a different directory. |
||
==Command-line tools== |
|||
===Deferred target invalidation hazards=== |
|||
Significant hazards lurk in the use of hard links schemes that either: |
|||
Windows comes with several tools capable of creating and manipulating NTFS links. |
|||
* '''[[PowerShell]]:''' The <code>New-Item</code> cmdlet of [[Windows PowerShell]] that can create empty files, folders, junctions, and hard links.<ref>{{cite web |title=New-Item (PowerShell 3.0) |url=https://docs.microsoft.com/en-us/previous-versions/powershell/module/microsoft.powershell.management/new-item?view=powershell-3.0 |website=Microsoft Docs |publisher=[[Microsoft]] |date=22 June 2020 |quote=If your location is in a FileSystem drive, the following values are allowed: If your location is in a FileSystem drive, the following values are allowed: File[,] Directory[,] Junction[,] HardLink}}</ref> In PowerShell 5.0 and later, it can create symbolic links as well.<ref>{{cite web |title=New-Item (PowerShell 5.0) |url=https://learn.microsoft.com/en-us/previous-versions/powershell/module/microsoft.powershell.management/new-item?view=powershell-5.0#-itemtype |website=Microsoft Docs |publisher=[[Microsoft]] |date=22 June 2020}}</ref> The <code>Get-Item</code> and <code>Get-ChildItem</code> cmdlets can be used to interrogate file system objects, and if they are NTFS links, find information about them. The <code>Remove-Item</code> cmdlet can remove said items, although there has been a record of a bug preventing this cmdlet from working properly.<ref>{{cite web |title=Fix Remove-Item <symbolic link to directory> |url=https://github.com/PowerShell/PowerShell/issues/621 |website=PowerShell repo |publisher=[[Microsoft]] |date=4 March 2016 |via=[[GitHub]]}}</ref> |
|||
* '''[[Windows Command Prompt]]:''' Starting with Windows Vista and Windows Server 2008, the <code>mklink</code> internal command can create junctions, hard links, and symbolic links.<ref name="mklink">{{cite web |title=Mklink |url=https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753194(v=ws.10) |website=Microsoft Docs |publisher=[[Microsoft]] |date=18 April 2012}}</ref> This command is also available in [[ReactOS]].<ref>{{cite web |title=mklink.c |url=https://github.com/reactos/reactos/blob/master/base/shell/cmd/mklink.c |website=reactos repo |date=3 October 2017 |via=[[GitHub.com]] |publisher=ReactOS Deutschland e.V.}}</ref> In addition, the venerable <code>[[dir (command)|dir]]</code> command can display and filter junction points via the <code>/aL</code> switch.<ref>{{cite web |title=Dir |url=https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc755121(v=ws.10) |website=Microsoft Docs |publisher=[[Microsoft]] |date=18 April 2012}}</ref> Finally, the <code>rd</code> command (also known as <code>rmdir</code>) can delete junction points. |
|||
* '''fsutil.exe:''' A command-line utility introduced with [[Windows 2000]]. Its <code>hardlink</code> sub-command can make hard links or list hard links associated with a file.<ref>{{cite web |title=Fsutil hardlink |url=https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc788097(v=ws.10) |website=Microsoft Docs |publisher=[[Microsoft]] |date=18 April 2012}}</ref> Another sub-command, <code>reparsepoint</code>, can query or delete [[reparse point]]s, the file system objects that make up junction points, hard links, and symbolic links.<ref>{{cite web |title=Fsutil reparsepoint |url=https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc785451(v=ws.10) |website=Microsoft Docs |publisher=[[Microsoft]] |date=18 April 2012}}</ref> |
|||
In addition, the following utilities can create NTFS links, even though they don't come with Windows. |
|||
* '''{{not a typo|linkd}}:''' It is a component of the [[Resource Kit]] for [[Windows 2000]] and [[Windows Server 2003]].<ref>{{Cite web|date=2015-03-10|title=Download Windows Server 2003 Resource Kit Tools |website=Download Center|url=http://www.microsoft.com/en-us/download/details.aspx?id=17657|url-status=live|archive-url=https://web.archive.org/web/20150310111937/http://www.microsoft.com/en-us/download/details.aspx?id=17657|archive-date=2015-03-10}}</ref> It can make junction points.<ref>{{Cite web|date=2015-03-09|title=How to create and manipulate NTFS junction points|url=http://support.microsoft.com/kb/205524/en-us|url-status=live|archive-url=https://web.archive.org/web/20150309001902/http://support.microsoft.com/kb/205524/en-us|archive-date=2015-03-09}}</ref> |
|||
* '''junction:''' A free command-line utility from Microsoft, it can create or delete junctions.<ref name="junction.exe">{{cite web |title=Junction v1.07 |url=https://docs.microsoft.com/en-us/sysinternals/downloads/junction |website=Sysinternals |publisher=[[Microsoft]] |date=4 July 2016}}</ref> |
|||
* '''PowerShell Community Extensions (PSCX):''' Hosted on Microsoft PowerShell Gallery,<ref>{{cite web |title=Pscx |url=https://www.powershellgallery.com/packages/Pscx/ |website=PowerShell Gallery |publisher=[[Microsoft]] |date=17 January 2018}}</ref> this module adds several cmdlets for dealing with NTFS links, including: New-Hardlink, New-Junction, Get-ReparsePoint, Remove-ReparsePoint, and New-Symlink.<ref>{{cite web |last1=Hill |first1=Keith |last2=Grehan |first2=Oisin |title=README.md |url=https://github.com/Pscx/Pscx/blob/master/README.md |website=pscx repo |date=17 January 2018 |via=[[GitHub]]}}</ref> |
|||
==APIs== |
|||
To create hard links, apps may use the [https://docs.microsoft.com/en-us/windows/win32/enwiki/api/winbase/nf-winbase-createhardlinkw {{mono|CreateHardLink()}}] function of [[Windows API]]. All versions of the [[Windows NT family]] can use <code>GetFileInformationByHandle()</code> to determine the number of hard links associated with a file. There can be up to 1024 links associated with an MFT entry. Similarly, the [https://docs.microsoft.com/en-us/windows/win32/enwiki/api/winbase/nf-winbase-createsymboliclinkw {{mono|CreateSymbolicLink()}}] function can create symbolic links. Junctions are more complex to create. They require manual [[reparse point]] information filling.<ref>{{cite web |title=NTFS Links, Directory Junctions, and Windows Shortcuts |
|||
|url=http://www.flexhex.com/docs/articles/hard-links.phtml |
|||
|website=www.flexhex.com |
|||
|access-date=4 October 2019 |
|||
|url-status=dead |
|||
|archive-url=http://web.archive.org/web/20210125194800/http://www.flexhex.com/docs/articles/hard-links.phtml |
|||
|archive-date=25 January 2021 |
|||
}}</ref> A code example is found in [[libuv]].<ref>{{cite web |title=libuv/src/win/fs.c |url=https://github.com/libuv/libuv/blob/5500253cac6fb4918aa75bde875794a7bfbdb2f0/src/win/fs.c#L2288 |website=GitHub |access-date=12 December 2019}}</ref> Junctions are defined for directories only: although the API does not fail when one creates a junction pointing to a file, the junction will not be interpreted successfully when used later. |
|||
Junctions and symbolic links, even those pointing to directories, can be removed with <code>pNtSetInformationFile</code>. Libuv's implementation of <code>unlink</code> on Windows demonstrates this use.<ref>{{cite web |title=libuv/src/win/fs.c fs__unlink |url=https://github.com/libuv/libuv/blob/5500253cac6fb4918aa75bde875794a7bfbdb2f0/src/win/fs.c#L1100 |website=GitHub |access-date=12 December 2019}}</ref> Alternatively, the .NET <code>System.IO.Directory.Delete()</code> method works on them as well.<ref name=psNet>{{cite web |title=PowerShell Remove Junction |url=https://stackoverflow.com/a/44060418 |website=StackOverflow |access-date=12 December 2019}}</ref> |
|||
==Hazards== |
|||
===Consistency=== |
|||
Symbolic links and NTFS junctions can point to non-existent targets because the operating system does not continuously ensure that the target exists.<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/aa365460(VS.85).aspx|title=Programming Considerations (Windows)|website=msdn.microsoft.com|date=March 4, 2021 }}</ref> |
|||
Additional hazards lurk in the use of NTFS directory junctions that: |
|||
* include links that refer to their own parent folders, such as creating hard link <code>X:\path\to\parent</code> which points to either <code>X:\path\</code> or <code>X:\path\to\</code>, or |
* include links that refer to their own parent folders, such as creating hard link <code>X:\path\to\parent</code> which points to either <code>X:\path\</code> or <code>X:\path\to\</code>, or |
||
* specify targets by using volume drive letters, such as <code>X:</code>, in <code>X:\some\path\</code>. |
* specify targets by using volume drive letters, such as <code>X:</code>, in <code>X:\some\path\</code>. |
||
===Recursive structure=== |
|||
The problem in the first case is that it creates recursive paths, which further implies infinite recursion in the directory structure. By introducing reentrancy, the presence of one or more directory junctions changes the structure of the file system from a simple [[Tree (data structure)|proper tree]] into a [[directed graph]], but recursive linking further complicates the graph-theoretical character from [[Directed acyclic graph|acyclic]] to cyclic. Since the same files and directories can now be encountered through multiple paths, applications which traverse reentrant or recursive structures naively may give incorrect or incoherent results, or may never terminate. Worse, if recursively ''deleting'', such programs may attempt to delete a parent of the directory it is currently traversing. |
The problem in the first case is that it creates recursive paths, which further implies infinite recursion in the directory structure. By introducing reentrancy, the presence of one or more directory junctions changes the structure of the file system from a simple [[Tree (data structure)|proper tree]] into a [[directed graph]], but recursive linking further complicates the graph-theoretical character from [[Directed acyclic graph|acyclic]] to cyclic. Since the same files and directories can now be encountered through multiple paths, applications which traverse reentrant or recursive structures naively may give incorrect or incoherent results, or may never terminate. Worse, if recursively ''deleting'', such programs may attempt to delete a parent of the directory it is currently traversing. |
||
Note that both of the conditions listed above exist in the system of hard links established on the <code>C:</code> drive in the default Windows setup. For example, every [[Microsoft Windows|Windows 10]] installation defines the recursive path: |
Note that both of the conditions listed above exist in the system of hard links established on the <code>C:</code> drive in the default Windows setup. For example, every [[Microsoft Windows|Windows 10]] installation defines the recursive path: |
||
<pre>C:\ProgramData\ |
<pre>C:\ProgramData\ |
||
C:\ProgramData\Application Data\ |
C:\ProgramData\Application Data\ |
||
Line 69: | Line 101: | ||
C:\ProgramData\Application Data\Application Data\Application Data\Application Data\ |
C:\ProgramData\Application Data\Application Data\Application Data\Application Data\ |
||
C:\ProgramData\Application Data\Application Data\Application Data\Application Data\Application Data\ ...</pre> |
C:\ProgramData\Application Data\Application Data\Application Data\Application Data\Application Data\ ...</pre> |
||
Each additional path name in this seemingly infinite set is an actual valid Windows path which refers to the same location. In practice, path names are limited by the 260-character DOS path limit (or newer 32,767 character limit), but truncation may result in incomplete or invalid path and file names. Whenever a copy of a Windows installation is archived, with directory junctions intact, to another volume on the same—or worse—''another'' computer, the archived copy may still incorporate active folders from the running installation. For example, depending on the method used for copying, a backup copy of a Windows drive <code>X:\archive\...</code> will include a hard link called <code>X:\archive\Users\USERNAME\My Documents</code> which still points to folder <code>C:\Users\USERNAME\Documents\</code> in the current, active installation. |
Each additional path name in this seemingly infinite set is an actual valid Windows path which refers to the same location. In practice, path names are limited by the 260-character DOS path limit (or newer 32,767 character limit), but truncation may result in incomplete or invalid path and file names. Whenever a copy of a Windows installation is archived, with directory junctions intact, to another volume on the same—or worse—''another'' computer, the archived copy may still incorporate active folders from the running installation. For example, depending on the method used for copying, a backup copy of a Windows drive <code>X:\archive\...</code> will include a hard link called <code>X:\archive\Users\USERNAME\My Documents</code> which still points to folder <code>C:\Users\USERNAME\Documents\</code> in the current, active installation. |
||
===Cross-volume traversal=== |
|||
The second form of deferred target mis-referral, while conceptually simpler, can have more severe consequences. When a self-consistent volume or directory structure containing hard links which use volume drive-letter path names is copied or moved to another volume (or when the drive letter of a volume is reassigned by some other means), such links may no longer point to the corresponding target ''in the copied structure''. Again the results depend on the software that was used for copying; while some programs may intercede by modifying any fully subsumed hard links in the copy in order to preserve structural consistency, others may ignore, copy exactly, or even traverse into hard links, copying their contents. |
The second form of deferred target mis-referral, while conceptually simpler, can have more severe consequences. When a self-consistent volume or directory structure containing hard links which use volume drive-letter path names is copied or moved to another volume (or when the drive letter of a volume is reassigned by some other means), such links may no longer point to the corresponding target ''in the copied structure''. Again the results depend on the software that was used for copying; while some programs may intercede by modifying any fully subsumed hard links in the copy in order to preserve structural consistency, others may ignore, copy exactly, or even traverse into hard links, copying their contents. |
||
The serious problems occur if hard links are copied exactly such that they become, in the new copy, cross-volume hard links which still point to original files and folders on the source volume. Unintentional cross-volume hard links, such as hard links in an "archive" folder which still point to locations on the original volume (according to drive letter), are catastrophes waiting to happen. For example, deleting what is much later presumed to be an unused archive directory on |
The serious problems occur if hard links are copied exactly such that they become, in the new copy, cross-volume hard links which still point to original files and folders on the source volume. Unintentional cross-volume hard links, such as hard links in an "archive" folder which still point to locations on the original volume (according to drive letter), are catastrophes waiting to happen. For example, deleting what is much later presumed to be an unused archive directory on a disused backup volume may result in deleting current, active user data or system files. |
||
A preventative measure for the drive-letter hazard is to use volume GUID path syntax,<ref>{{Cite web|url=https://docs.microsoft.com/en-us/dotnet/standard/io/file-path-formats#dos-device-paths|title=File path formats on Windows systems|website=docs.microsoft.com}}</ref> rather than paths containing volume drive letters, when specifying the target path for a directory junction. For example, consider creating an alias for <code>X:\Some\Other\Path</code> at <code>X:\Some\Path\Foo</code>: |
A preventative measure for the drive-letter hazard is to use volume GUID path syntax,<ref>{{Cite web|url=https://docs.microsoft.com/en-us/dotnet/standard/io/file-path-formats#dos-device-paths|title=File path formats on Windows systems|website=docs.microsoft.com|date=December 14, 2022 }}</ref> rather than paths containing volume drive letters, when specifying the target path for a directory junction. For example, consider creating an alias for <code>X:\Some\Other\Path</code> at <code>X:\Some\Path\Foo</code>: |
||
{{code|2=doscon|X:\Some\Path>linkd Foo X:\Some\Other\Path}} |
{{code|2=doscon|X:\Some\Path> linkd Foo X:\Some\Other\Path}} |
||
As described above, if the folder structure that contains the resulting link is moved to a disk with a drive letter other than <code>X:</code>, or if the letter is changed on drive <code>X:</code> itself, the data content at the target location is vulnerable to accidental corruption or malicious abuse. A more resilient version of this link can partially mitigate this risk by referencing the target volume by its GUID identifier value (which can be discovered by running the <code>fsutil volume list</code> command). |
As described above, if the folder structure that contains the resulting link is moved to a disk with a drive letter other than <code>X:</code>, or if the letter is changed on drive <code>X:</code> itself, the data content at the target location is vulnerable to accidental corruption or malicious abuse. A more resilient version of this link can partially mitigate this risk by referencing the target volume by its GUID identifier value (which can be discovered by running the <code>fsutil volume list</code> command). |
||
{{code|2=doscon|X:\Some\Path>linkd Foo \\?\Volume{12345678-abcd-1234--abcdefghijkl}\Some\Other\Path}} |
{{code|2=doscon|X:\Some\Path> linkd Foo \\?\Volume{12345678-abcd-1234--abcdefghijkl}\Some\Other\Path}} |
||
Doing so ensures that the junction will remain valid if drive letter <code>X:</code> is changed by any means. |
Doing so ensures that the junction will remain valid if drive letter <code>X:</code> is changed by any means. |
||
Line 88: | Line 120: | ||
As for a proactive means of avoiding directory junction disasters, the command <code>dir /AL /S /B "X:\Some\Path"</code> can be used to obtain, for careful analysis prior to committing any irreversible file system alterations, a list of all hard links "below" a certain file system location. While by definition every link in the resulting list has a path name that starts with <code>X:\Some\Path\</code>, if any of those hard links contains a target which is not subsumed by <code>X:\Some\Path</code>, then the specified scope has been escaped, and the starting directory you specified is not fully-subsuming. Extra caution may be indicated in this case, since the specified directory includes files and directories which reside on other physical volumes, or whose own parent-traversal-to-root does not include the specified directory. |
As for a proactive means of avoiding directory junction disasters, the command <code>dir /AL /S /B "X:\Some\Path"</code> can be used to obtain, for careful analysis prior to committing any irreversible file system alterations, a list of all hard links "below" a certain file system location. While by definition every link in the resulting list has a path name that starts with <code>X:\Some\Path\</code>, if any of those hard links contains a target which is not subsumed by <code>X:\Some\Path</code>, then the specified scope has been escaped, and the starting directory you specified is not fully-subsuming. Extra caution may be indicated in this case, since the specified directory includes files and directories which reside on other physical volumes, or whose own parent-traversal-to-root does not include the specified directory. |
||
==Limitations== |
|||
==Command-line tools== |
|||
===Privilege requirements=== |
|||
Windows comes with several tools capable of creating and manipulating NTFS links. |
|||
The default security settings in Windows disallow non-elevated administrators and all non-administrators from creating symbolic links but not junctions. This behavior can be changed running "secpol.msc", the Local Security Policy management console (under: Security Settings\Local Policies\User Rights Assignment\Create symbolic links). It can be worked around by starting [[cmd.exe]] with ''Run as administrator'' option or the <code>[[runas]]</code> command. Starting with Windows 10 Insiders build 14972 the requirement for elevated administrator privileges was removed in Windows "Developer Mode", allowing symlinks to be created without needing to elevate the console as administrator. At the API level, a {{code|SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE}} flag is supplied for this purpose.<ref>{{cite web|url=https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/#Ed9Olhkz6hJp4KWV.97|title=Symlinks in Windows 10! - Windows Developer BlogWindows Developer Blog|website=blogs.windows.com|date=2 December 2016}}</ref> |
|||
* '''[[PowerShell]]:''' The <code>New-Item</code> cmdlet of [[Windows PowerShell]] that can create empty files, folders, junctions, and hard links.<ref>{{cite web |title=New-Item (PowerShell 3.0) |url=https://docs.microsoft.com/en-us/previous-versions/powershell/module/microsoft.powershell.management/new-item?view=powershell-3.0 |website=Microsoft Docs |publisher=[[Microsoft]] |date=22 June 2020 |quote=If your location is in a FileSystem drive, the following values are allowed: If your location is in a FileSystem drive, the following values are allowed: File[,] Directory[,] Junction[,] HardLink}}</ref> In PowerShell 5.0 and later, it can create symbolic links as well.<ref>{{cite web |title=New-Item (PowerShell 5.0) |url=https://docs.microsoft.com/en-us/previous-versions/powershell/module/microsoft.powershell.management/new-item?view=powershell-5.0 |website=Microsoft Docs |publisher=[[Microsoft]] |date=22 June 2020}}</ref> The <code>Get-Item</code> and <code>Get-ChildItem</code> cmdlets can be used to interrogate file system objects, and if they are NTFS links, find information about them. The <code>Remove-Item</code> cmdlet can remove said items, although there has been a record of a bug preventing this cmdlet from working properly.<ref>{{cite web |title=Fix Remove-Item <symbolic link to directory> |url=https://github.com/PowerShell/PowerShell/issues/621 |website=PowerShell repo |publisher=[[Microsoft]] |date=4 March 2016 |via=[[GitHub]]}}</ref> |
|||
* '''[[Windows Command Prompt]]:''' Starting with Windows Vista and Windows Server 2008, the <code>mklink</code> internal command can create junctions, hard links, and symbolic links.<ref name="mklink">{{cite web |title=Mklink |url=https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753194(v=ws.10) |website=Microsoft Docs |publisher=[[Microsoft]] |date=18 April 2012}}</ref> This command is also available in [[ReactOS]].<ref>{{cite web |title=mklink.c |url=https://github.com/reactos/reactos/blob/master/base/shell/cmd/mklink.c |website=reactos repo |date=3 October 2017 |via=[[GitHub.com]] |publisher=ReactOS Deutschland e.V.}}</ref> In addition, the venerable <code>[[dir (command)|dir]]</code> command can display and filter junction points via the <code>/aL</code> switch.<ref>{{cite web |title=Dir |url=https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc755121(v=ws.10) |website=Microsoft Docs |publisher=[[Microsoft]] |date=18 April 2012}}</ref> Finally, the <code>rd</code> command (also known as <code>rmdir</code>) can delete junction points. |
|||
* '''fsutil.exe:''' A command-line utility introduced with [[Windows 2000]]. Its <code>hardlink</code> sub-command can make hard links or list hard links associated with a file.<ref>{{cite web |title=Fsutil hardlink |url=https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc788097(v=ws.10) |website=Microsoft Docs |publisher=[[Microsoft]] |date=18 April 2012}}</ref> Another sub-command, <code>reparsepoint</code>, can query or delete [[reparse point]]s, the file system objects that make up junction points, hard links, and symbolic links.<ref>{{cite web |title=Fsutil reparsepoint |url=https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc785451(v=ws.10) |website=Microsoft Docs |publisher=[[Microsoft]] |date=18 April 2012}}</ref> |
|||
===Boot time=== |
|||
In addition, the following utilities can create NTFS links, even though they don't come with Windows. |
|||
The [[Booting process of Windows|Windows startup process]] does not support junction points, so it is impossible to redirect certain system folders: |
|||
* '''{{not a typo|linkd}}:''' It is a component of the [[Resource Kit]] for [[Windows 2000]] and [[Windows Server 2003]].<ref>{{Cite web|date=2015-03-10|title=Download Windows Server 2003 Resource Kit Tools |website=Download Center|url=http://www.microsoft.com/en-us/download/details.aspx?id=17657|url-status=live|archive-url=https://web.archive.org/web/20150310111937/http://www.microsoft.com/en-us/download/details.aspx?id=17657|archive-date=2015-03-10}}</ref> It can make junction points.<ref>{{Cite web|date=2015-03-09|title=How to create and manipulate NTFS junction points|url=http://support.microsoft.com/kb/205524/en-us|url-status=live|archive-url=https://web.archive.org/web/20150309001902/http://support.microsoft.com/kb/205524/en-us|archive-date=2015-03-09}}</ref> |
|||
* '''junction:''' A free command-line utility from Microsoft, it can create or delete junctions.<ref name="junction.exe">{{cite web |title=Junction v1.07 |url=https://docs.microsoft.com/en-us/sysinternals/downloads/junction |website=Sysinternals |publisher=[[Microsoft]] |date=4 July 2016}}</ref> |
|||
* '''PowerShell Community Extensions (PSCX):''' Hosted on Microsoft PowerShell Gallery,<ref>{{cite web |title=Pscx |url=https://www.powershellgallery.com/packages/Pscx/ |website=PowerShell Gallery |publisher=[[Microsoft]] |date=17 January 2018}}</ref> this module adds several cmdlets for dealing with NTFS links, including: New-Hardlink, New-Junction, Get-ReparsePoint, Remove-ReparsePoint, and New-Symlink.<ref>{{cite web |last1=Hill |first1=Keith |last2=Grehan |first2=Oisin |title=README.md |url=https://github.com/Pscx/Pscx/blob/master/README.md |website=pscx repo |date=17 January 2018 |via=[[GitHub]]}}</ref> |
|||
==APIs== |
|||
To create hard links, apps may use the [https://docs.microsoft.com/en-us/windows/win32/enwiki/api/winbase/nf-winbase-createhardlinkw {{mono|CreateHardLink()}}] function of [[Windows API]]. All versions of the [[Windows NT family]] can use <code>GetFileInformationByHandle()</code> to determine the number of hard links associated with a file. There can be up to 1024 links associated with an MFT entry. Similarly, the [https://docs.microsoft.com/en-us/windows/win32/enwiki/api/winbase/nf-winbase-createsymboliclinkw {{mono|CreateSymbolicLink()}}] function can create symbolic links. Junctions are more complex to create. They require manual [[reparse point]] information filling.<ref>{{cite web |title=NTFS Links, Directory Junctions, and Windows Shortcuts |url=http://www.flexhex.com/docs/articles/hard-links.phtml |website=www.flexhex.com |access-date=4 October 2019}}</ref> A code example is found in [[libuv]].<ref>{{cite web |title=libuv/src/win/fs.c |url=https://github.com/libuv/libuv/blob/5500253cac6fb4918aa75bde875794a7bfbdb2f0/src/win/fs.c#L2288 |website=GitHub |access-date=12 December 2019}}</ref> Junctions are defined for directories only: although the API does not fail when one creates a junction pointing to a file, the junction will not be interpreted successfully when used later. |
|||
Junctions and symbolic links, even those pointing to directories, can be removed with <code>pNtSetInformationFile</code>. Libuv's implementation of <code>unlink</code> on Windows demonstrates this use.<ref>{{cite web |title=libuv/src/win/fs.c fs__unlink |url=https://github.com/libuv/libuv/blob/5500253cac6fb4918aa75bde875794a7bfbdb2f0/src/win/fs.c#L1100 |website=GitHub |access-date=12 December 2019}}</ref> Alternatively, the .NET <code>System.IO.Directory.Delete()</code> method works on them as well.<ref name=psNet>{{cite web |title=PowerShell Remove Junction |url=https://stackoverflow.com/a/44060418 |website=StackOverflow |access-date=12 December 2019}}</ref> |
|||
==Other properties== |
|||
Symbolic links can point to non-existent targets because the operating system does not check to see if the target exists.<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/aa365460(VS.85).aspx|title=Programming Considerations (Windows)|website=msdn.microsoft.com}}</ref> |
|||
==Limitations== |
|||
Symbolic links do not work at boot, so it's impossible to redirect e.g.: |
|||
* hiberfil.sys |
|||
* \Windows |
* \Windows |
||
* \Windows\ |
* \Windows\System32 |
||
* \Windows\ |
* \Windows\System32\Config |
||
Other critical system boot files, such as The sleep image file <code>hiberfil.sys</code>, also do not support redirecetion. |
|||
Windows Installer does not fully support symbolic links. A redirected \Windows\Installer will cause most .msi-based Windows installers to fail with error 2755 and/or error 1632. |
|||
===System-defined locations=== |
|||
Nevertheless, it is possible to redirect: |
|||
It is technically possible to redirect the following non-critical system folder locations: |
|||
* \Users |
|||
* \Documents and Settings |
* \Documents and Settings |
||
* \ProgramData |
* \ProgramData |
||
* \Program Files |
* \Program Files |
||
* \Program Files (x86) |
* \Program Files (x86) |
||
* \Users |
|||
Doing this may lead to long-term Windows reliability or compatibility issues. Creating junctions for <code>\Users</code> and <code>\ProgramData</code> pointing to another drive is not recommended as it breaks updates and Windows Store Apps.<ref name="auto">{{Cite web|url = http://support.microsoft.com/kb/949977|title = Relocation of the Users directory and the ProgramData directory to a drive other than the drive that contains the Windows directory|access-date = 2015-03-12}}</ref> |
|||
Creating |
Creating junctions for \Users, \ProgramData, <code>\Program Files</code> or <code>\Program Files (x86)</code> pointing to other locations breaks installation or upgrade of Windows.<ref name="auto1">{{Cite web|url = http://support.microsoft.com/kb/2876597|title = You encounter an error when trying to install Windows 8.1 due to redirecting the Users or Program Files folder to another partition|access-date = 2015-03-12}}</ref> |
||
Creating |
Creating junctions for <code>\Program Files</code> or <code>\Program Files (x86)</code> pointing to another drive breaks Windows' [[Management features new to Windows Vista#Component Based Servicing|Component Based Servicing]] which hardlinks files from its repository \Windows\SxS to their installation directory.{{cn|date=September 2017}} |
||
== |
===Windows installer=== |
||
[[Windows Installer]] does not fully support symbolic links. Redirecting <code>\Windows\Installer</code> will cause most .msi-based Windows installers to fail with error 2755 and/or error 1632. |
|||
===Symbolic link support in Windows XP=== |
|||
Since Windows XP uses the same NTFS format version as later releases, it's feasible to enable symbolic links support in it. For using NTFS symbolic links under Windows 2000 and XP, a third-party driver exists that does it by installing itself as a file system filter.<ref name="winxp">{{cite web|url=http://schinagl.priv.at/nt/ln/ln.html#symboliclinksforwindowsxp |title=ln - commandline hardlinks - Symbolic links for Windows XP |author=Hermann Schinagl|date=August 23, 2013}}</ref><ref>{{Cite web|url=http://emk.name/symlink.html|title=リンク/ジャンクション作成ツール|website=emk.name}}</ref> |
Since Windows XP uses the same NTFS format version as later releases, it's feasible to enable symbolic links support in it. For using NTFS symbolic links under Windows 2000 and XP, a third-party driver exists that does it by installing itself as a file system filter.<ref name="winxp">{{cite web|url=http://schinagl.priv.at/nt/ln/ln.html#symboliclinksforwindowsxp |title=ln - commandline hardlinks - Symbolic links for Windows XP |author=Hermann Schinagl|date=August 23, 2013}}</ref><ref>{{Cite web|url=http://emk.name/symlink.html|title=リンク/ジャンクション作成ツール|website=emk.name}}</ref> |
||
==History== |
|||
Symbolic links to directories or volumes, called [[NTFS junction point|junction points]] and mount points, were introduced with NTFS 3.0 that shipped with Windows 2000. From NTFS 3.1 onwards, symbolic links can be created for any kind of file system object. NTFS 3.1 was introduced together with [[Windows XP]], but the functionality was not made available (through ntfs.sys) to user mode applications. Third-party filter drivers {{ndash}} such as Masatoshi Kimura's opensource <code>senable</code> driver {{ndash}} could however be installed to make the feature available in user mode as well. The ntfs.sys released with [[Windows Vista]] made the functionality available to user mode applications by default. |
|||
Since NTFS 3.1, a symbolic link can also point to a file or remote [[Server Message Block|SMB]] network path. While NTFS junction points support only absolute paths on local drives, the NTFS symbolic links allow linking using relative paths. Additionally, the NTFS symbolic link implementation provides full support for cross-filesystem links. However, the functionality enabling cross-host symbolic links requires that the remote system also support them, which effectively limits their support to Windows Vista and later Windows operating systems. |
|||
==See also== |
==See also== |
||
Line 150: | Line 174: | ||
* [https://technet.microsoft.com/sysinternals/bb896768 Junction] command line utility from Microsoft TechNet |
* [https://technet.microsoft.com/sysinternals/bb896768 Junction] command line utility from Microsoft TechNet |
||
* [https://web.archive.org/web/20040409134503/http://www.codeproject.com/w2k/junctionpoints.asp Codeproject Article] – discussion on the source code of a junction point utility, aimed at programmers |
* [https://web.archive.org/web/20040409134503/http://www.codeproject.com/w2k/junctionpoints.asp Codeproject Article] – discussion on the source code of a junction point utility, aimed at programmers |
||
* [https://www.pcmag.com/article2/0,4149,1183816,00.asp PC Mag Article] about adding any directory to the start menu (allowing a preview within the startmenu as a submenu). |
* [https://www.pcmag.com/article2/0,4149,1183816,00.asp PC Mag Article] {{Webarchive|url=https://web.archive.org/web/20081211115631/http://www.pcmag.com/article2/0,4149,1183816,00.asp |date=2008-12-11 }} about adding any directory to the start menu (allowing a preview within the startmenu as a submenu). |
||
{{Windows Components}} |
{{Windows Components}} |
Latest revision as of 13:10, 16 October 2024
NTFS links are the abstraction used in the NTFS file system—the default file system for all Microsoft Windows versions belonging to the Windows NT family—to associate pathnames and certain kinds of metadata, with entries in the NTFS Master File Table (MFT). NTFS broadly adopts a pattern akin to typical Unix file systems in the way it stores and references file data and metadata; the most significant difference is that in NTFS, the MFT "takes the place of" inodes, fulfilling most of the functions which inodes fulfill in a typical Unix filesystem.
In NTFS, an entity in the filesystem fundamentally exists as: a record stored in the MFT of an NTFS volume, the MFT being the core database of the NTFS filesystem; and, any attributes and NTFS streams associated with said record. A link in NTFS is itself a record, stored in the MFT, which "points" to another MFT record: the target of the link. Links are the file "entries" in the volume's hierarchical file tree: an NTFS pathname such as \foo.exe or \foobar\baz.txt is a link. If the volume containing said pathnames were mapped to D: in a Windows system, these could be referenced as D:\foo.exe and D:\foobar\baz.txt. (Compare and contrast with typical Unix file systems, where a link is an entry in a directory—directories themselves being just a type of file stored in the filesystem—pointing either to another link, or to an inode.)
Types of links
[edit]NTFS has four types of links. These map relatively closely to the generic hard link and soft link concepts which modern file systems tend to follow.
Hard links
[edit]Hard links are typical in behavior. A hard link "points" to an MFT record. That target record will be the record for a "regular" file, such as a text file or executable (assuming the NTFS volume is in a normal "healthy" state). Compare with a typical Unix file system, where a hard link points to an inode. As in such file systems, an NTFS hard link cannot point to a directory.
A typical new file creation event on an NTFS volume, then, simply involves NTFS allocating and creating one new MFT record, for storing the new file entity's file metadata—including, about any of the data clusters assigned to the file, and the file's data streams; one MFT record for a hard link which points to the first newly-created MFT record as its target; storing a reference to the hard link in a directory file; and setting the reference count of both these MFT records to 1. Any file name provided as part of the file creation event is stored in the hard link. An MFT record can be the target of up to 1024 hard links; each time a new hard link is successfully created, targeting a previously extant MFT record, the target's reference count is incremented.
Symmetrically, the immediate tasks performed by NTFS in a typical file deletion event, when deleting a hard link, are simply: removing the reference to the link from the directory file containing it (the root directory, if applicable); and decrementing by 1 the reference counts of the MFT record targeted by the link, and, of the entry containing the hard link itself. Any MFT record which now has a refcount of 0, is now in the "deleted" state: all its associated resources are considered "free" by NTFS, to be freely overwritten and used as needed.
Junction points
[edit]Junction points are NTFS reparse points and operate similarly to symbolic links in Unix or Linux, but are only defined for directories, and may only be absolute paths on local filesystems (as opposed to remote filesystems being accessed). They are created and behave in a similar way to hard links, except that if the target directory is renamed, moved, or deleted, the link will no longer be valid.[1][2]
Symbolic links
[edit]Symbolic links are reparse points which operate similarly to Junction Points, or symbolic links in Unix or Linux, and accept relative paths and paths to files as well as directories. Support for directory and UNC paths were added in NTFS 3.1.
All NTFS links are intended to be transparent to applications. This means that the application accessing a link will be seamlessly redirected by the file system driver, and no special handling is needed. To users, they appear as normal directories or files. This also leads to an aliasing effect: writes to a link will pass the write to the underlying, linked file or MFT entry.
Symbolic links and junction points contain the path to the linked file, and a tag identifying the driver which implements the behaviour. Because they record the path, they can link to files on other volumes or even remote files. However this also means that if the referenced file is deleted or renamed, the link becomes invalid, and if the referenced file or directory is replaced with another, the link will now refer to the new file or directory.
Shortcut files
[edit]An NTFS symbolic link is not the same as a Windows shortcut file, which is a regular file. The latter may be created on any filesystem (such as the earlier FAT32), may contain metadata (such as an icon to display when the shortcut is viewed in Remove links), and is not transparent to applications.
Implementations of unix-like environments for Windows such as Cygwin and Mingw can use shortcut files to emulate symbolic links where the host operating system does not support them, if configured to do so.
Examples of use
[edit]Built-in uses
[edit]- Windows Component Store (WinSxS) use hard links to keep track of different versions of DLLs stored on the hard disk drive.
- Basic installations of Windows Server 2008 used symlinks for \Users\All Users\ → \ProgramData\ redirection.
- Since Windows Vista, all versions of Windows have used a specific scheme of built-in directories and utilize hidden junctions to maintain backward compatibility with Windows XP and older. Examples of these junctions are:
C:\Documents and Settings
pointing toC:\Users
%USERPROFILE%\Application Data
pointing to%USERPROFILE%\AppData\Roaming
%USERPROFILE%\My Documents\My Pictures
pointing to%USERPROFILE%\Pictures
Program redirection
[edit]By setting a junction point that points to a directory containing a particular version of a piece of software, it may be possible to add another version of the software and redirect the junction point to point to the version desired.
Saving storage space
[edit]The contents of a junction use almost no storage space (they simply point to the original directory). If an administrator needs to have multiple points of entry to a large directory, junction points can be an effective solution. Junction points should not be confused with a copy of something as junctions simply point to the original. If directories need to be modified separately a junction cannot be used as it does not provide a distinct copy of the directory or files within.
Likewise, symbolic links and hard links are useful for merging the contents of individual files.
Circumventing predefined paths
[edit]Since reinstalling Windows (or installing a new version) often requires deleting the contents of the C:
drive, it is advantageous to create multiple partitions so only one partition needs to be deleted during the installation. However, some programs don't let the user choose the installation directory, or install some of their files to the C:
drive even when they are installed to a different drive. By creating a junction point, the program can be tricked into installing to a different directory.
Command-line tools
[edit]Windows comes with several tools capable of creating and manipulating NTFS links.
- PowerShell: The
New-Item
cmdlet of Windows PowerShell that can create empty files, folders, junctions, and hard links.[3] In PowerShell 5.0 and later, it can create symbolic links as well.[4] TheGet-Item
andGet-ChildItem
cmdlets can be used to interrogate file system objects, and if they are NTFS links, find information about them. TheRemove-Item
cmdlet can remove said items, although there has been a record of a bug preventing this cmdlet from working properly.[5] - Windows Command Prompt: Starting with Windows Vista and Windows Server 2008, the
mklink
internal command can create junctions, hard links, and symbolic links.[6] This command is also available in ReactOS.[7] In addition, the venerabledir
command can display and filter junction points via the/aL
switch.[8] Finally, therd
command (also known asrmdir
) can delete junction points. - fsutil.exe: A command-line utility introduced with Windows 2000. Its
hardlink
sub-command can make hard links or list hard links associated with a file.[9] Another sub-command,reparsepoint
, can query or delete reparse points, the file system objects that make up junction points, hard links, and symbolic links.[10]
In addition, the following utilities can create NTFS links, even though they don't come with Windows.
- linkd: It is a component of the Resource Kit for Windows 2000 and Windows Server 2003.[11] It can make junction points.[12]
- junction: A free command-line utility from Microsoft, it can create or delete junctions.[2]
- PowerShell Community Extensions (PSCX): Hosted on Microsoft PowerShell Gallery,[13] this module adds several cmdlets for dealing with NTFS links, including: New-Hardlink, New-Junction, Get-ReparsePoint, Remove-ReparsePoint, and New-Symlink.[14]
APIs
[edit]To create hard links, apps may use the CreateHardLink() function of Windows API. All versions of the Windows NT family can use GetFileInformationByHandle()
to determine the number of hard links associated with a file. There can be up to 1024 links associated with an MFT entry. Similarly, the CreateSymbolicLink() function can create symbolic links. Junctions are more complex to create. They require manual reparse point information filling.[15] A code example is found in libuv.[16] Junctions are defined for directories only: although the API does not fail when one creates a junction pointing to a file, the junction will not be interpreted successfully when used later.
Junctions and symbolic links, even those pointing to directories, can be removed with pNtSetInformationFile
. Libuv's implementation of unlink
on Windows demonstrates this use.[17] Alternatively, the .NET System.IO.Directory.Delete()
method works on them as well.[18]
Hazards
[edit]Consistency
[edit]Symbolic links and NTFS junctions can point to non-existent targets because the operating system does not continuously ensure that the target exists.[19]
Additional hazards lurk in the use of NTFS directory junctions that:
- include links that refer to their own parent folders, such as creating hard link
X:\path\to\parent
which points to eitherX:\path\
orX:\path\to\
, or - specify targets by using volume drive letters, such as
X:
, inX:\some\path\
.
Recursive structure
[edit]The problem in the first case is that it creates recursive paths, which further implies infinite recursion in the directory structure. By introducing reentrancy, the presence of one or more directory junctions changes the structure of the file system from a simple proper tree into a directed graph, but recursive linking further complicates the graph-theoretical character from acyclic to cyclic. Since the same files and directories can now be encountered through multiple paths, applications which traverse reentrant or recursive structures naively may give incorrect or incoherent results, or may never terminate. Worse, if recursively deleting, such programs may attempt to delete a parent of the directory it is currently traversing.
Note that both of the conditions listed above exist in the system of hard links established on the C:
drive in the default Windows setup. For example, every Windows 10 installation defines the recursive path:
C:\ProgramData\ C:\ProgramData\Application Data\ C:\ProgramData\Application Data\Application Data\ C:\ProgramData\Application Data\Application Data\Application Data\ C:\ProgramData\Application Data\Application Data\Application Data\Application Data\ C:\ProgramData\Application Data\Application Data\Application Data\Application Data\Application Data\ ...
Each additional path name in this seemingly infinite set is an actual valid Windows path which refers to the same location. In practice, path names are limited by the 260-character DOS path limit (or newer 32,767 character limit), but truncation may result in incomplete or invalid path and file names. Whenever a copy of a Windows installation is archived, with directory junctions intact, to another volume on the same—or worse—another computer, the archived copy may still incorporate active folders from the running installation. For example, depending on the method used for copying, a backup copy of a Windows drive X:\archive\...
will include a hard link called X:\archive\Users\USERNAME\My Documents
which still points to folder C:\Users\USERNAME\Documents\
in the current, active installation.
Cross-volume traversal
[edit]The second form of deferred target mis-referral, while conceptually simpler, can have more severe consequences. When a self-consistent volume or directory structure containing hard links which use volume drive-letter path names is copied or moved to another volume (or when the drive letter of a volume is reassigned by some other means), such links may no longer point to the corresponding target in the copied structure. Again the results depend on the software that was used for copying; while some programs may intercede by modifying any fully subsumed hard links in the copy in order to preserve structural consistency, others may ignore, copy exactly, or even traverse into hard links, copying their contents.
The serious problems occur if hard links are copied exactly such that they become, in the new copy, cross-volume hard links which still point to original files and folders on the source volume. Unintentional cross-volume hard links, such as hard links in an "archive" folder which still point to locations on the original volume (according to drive letter), are catastrophes waiting to happen. For example, deleting what is much later presumed to be an unused archive directory on a disused backup volume may result in deleting current, active user data or system files.
A preventative measure for the drive-letter hazard is to use volume GUID path syntax,[20] rather than paths containing volume drive letters, when specifying the target path for a directory junction. For example, consider creating an alias for X:\Some\Other\Path
at X:\Some\Path\Foo
:
X:\Some\Path> linkd Foo X:\Some\Other\Path
As described above, if the folder structure that contains the resulting link is moved to a disk with a drive letter other than X:
, or if the letter is changed on drive X:
itself, the data content at the target location is vulnerable to accidental corruption or malicious abuse. A more resilient version of this link can partially mitigate this risk by referencing the target volume by its GUID identifier value (which can be discovered by running the fsutil volume list
command).
X:\Some\Path> linkd Foo \\?\Volume{12345678-abcd-1234--abcdefghijkl}\Some\Other\Path
Doing so ensures that the junction will remain valid if drive letter X:
is changed by any means.
As for a proactive means of avoiding directory junction disasters, the command dir /AL /S /B "X:\Some\Path"
can be used to obtain, for careful analysis prior to committing any irreversible file system alterations, a list of all hard links "below" a certain file system location. While by definition every link in the resulting list has a path name that starts with X:\Some\Path\
, if any of those hard links contains a target which is not subsumed by X:\Some\Path
, then the specified scope has been escaped, and the starting directory you specified is not fully-subsuming. Extra caution may be indicated in this case, since the specified directory includes files and directories which reside on other physical volumes, or whose own parent-traversal-to-root does not include the specified directory.
Limitations
[edit]Privilege requirements
[edit]The default security settings in Windows disallow non-elevated administrators and all non-administrators from creating symbolic links but not junctions. This behavior can be changed running "secpol.msc", the Local Security Policy management console (under: Security Settings\Local Policies\User Rights Assignment\Create symbolic links). It can be worked around by starting cmd.exe with Run as administrator option or the runas
command. Starting with Windows 10 Insiders build 14972 the requirement for elevated administrator privileges was removed in Windows "Developer Mode", allowing symlinks to be created without needing to elevate the console as administrator. At the API level, a SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE
flag is supplied for this purpose.[21]
Boot time
[edit]The Windows startup process does not support junction points, so it is impossible to redirect certain system folders:
- \Windows
- \Windows\System32
- \Windows\System32\Config
Other critical system boot files, such as The sleep image file hiberfil.sys
, also do not support redirecetion.
System-defined locations
[edit]It is technically possible to redirect the following non-critical system folder locations:
- \Users
- \Documents and Settings
- \ProgramData
- \Program Files
- \Program Files (x86)
Doing this may lead to long-term Windows reliability or compatibility issues. Creating junctions for \Users
and \ProgramData
pointing to another drive is not recommended as it breaks updates and Windows Store Apps.[22]
Creating junctions for \Users, \ProgramData, \Program Files
or \Program Files (x86)
pointing to other locations breaks installation or upgrade of Windows.[23]
Creating junctions for \Program Files
or \Program Files (x86)
pointing to another drive breaks Windows' Component Based Servicing which hardlinks files from its repository \Windows\SxS to their installation directory.[citation needed]
Windows installer
[edit]Windows Installer does not fully support symbolic links. Redirecting \Windows\Installer
will cause most .msi-based Windows installers to fail with error 2755 and/or error 1632.
Symbolic link support in Windows XP
[edit]Since Windows XP uses the same NTFS format version as later releases, it's feasible to enable symbolic links support in it. For using NTFS symbolic links under Windows 2000 and XP, a third-party driver exists that does it by installing itself as a file system filter.[24][25]
History
[edit]Symbolic links to directories or volumes, called junction points and mount points, were introduced with NTFS 3.0 that shipped with Windows 2000. From NTFS 3.1 onwards, symbolic links can be created for any kind of file system object. NTFS 3.1 was introduced together with Windows XP, but the functionality was not made available (through ntfs.sys) to user mode applications. Third-party filter drivers – such as Masatoshi Kimura's opensource senable
driver – could however be installed to make the feature available in user mode as well. The ntfs.sys released with Windows Vista made the functionality available to user mode applications by default.
Since NTFS 3.1, a symbolic link can also point to a file or remote SMB network path. While NTFS junction points support only absolute paths on local drives, the NTFS symbolic links allow linking using relative paths. Additionally, the NTFS symbolic link implementation provides full support for cross-filesystem links. However, the functionality enabling cross-host symbolic links requires that the remote system also support them, which effectively limits their support to Windows Vista and later Windows operating systems.
See also
[edit]References
[edit]- ^ "Hard Links and Junctions". Windows Developer. Microsoft. May 31, 2018.
- ^ a b "Junction v1.07". Sysinternals. Microsoft. July 4, 2016.
- ^ "New-Item (PowerShell 3.0)". Microsoft Docs. Microsoft. June 22, 2020.
If your location is in a FileSystem drive, the following values are allowed: If your location is in a FileSystem drive, the following values are allowed: File[,] Directory[,] Junction[,] HardLink
- ^ "New-Item (PowerShell 5.0)". Microsoft Docs. Microsoft. June 22, 2020.
- ^ "Fix Remove-Item <symbolic link to directory>". PowerShell repo. Microsoft. March 4, 2016 – via GitHub.
- ^ "Mklink". Microsoft Docs. Microsoft. April 18, 2012.
- ^ "mklink.c". reactos repo. ReactOS Deutschland e.V. October 3, 2017 – via GitHub.com.
- ^ "Dir". Microsoft Docs. Microsoft. April 18, 2012.
- ^ "Fsutil hardlink". Microsoft Docs. Microsoft. April 18, 2012.
- ^ "Fsutil reparsepoint". Microsoft Docs. Microsoft. April 18, 2012.
- ^ "Download Windows Server 2003 Resource Kit Tools". Download Center. March 10, 2015. Archived from the original on March 10, 2015.
- ^ "How to create and manipulate NTFS junction points". March 9, 2015. Archived from the original on March 9, 2015.
- ^ "Pscx". PowerShell Gallery. Microsoft. January 17, 2018.
- ^ Hill, Keith; Grehan, Oisin (January 17, 2018). "README.md". pscx repo – via GitHub.
- ^ "NTFS Links, Directory Junctions, and Windows Shortcuts". www.flexhex.com. Archived from the original on January 25, 2021. Retrieved October 4, 2019.
- ^ "libuv/src/win/fs.c". GitHub. Retrieved December 12, 2019.
- ^ "libuv/src/win/fs.c fs__unlink". GitHub. Retrieved December 12, 2019.
- ^ "PowerShell Remove Junction". StackOverflow. Retrieved December 12, 2019.
- ^ "Programming Considerations (Windows)". msdn.microsoft.com. March 4, 2021.
- ^ "File path formats on Windows systems". docs.microsoft.com. December 14, 2022.
- ^ "Symlinks in Windows 10! - Windows Developer BlogWindows Developer Blog". blogs.windows.com. December 2, 2016.
- ^ "Relocation of the Users directory and the ProgramData directory to a drive other than the drive that contains the Windows directory". Retrieved March 12, 2015.
- ^ "You encounter an error when trying to install Windows 8.1 due to redirecting the Users or Program Files folder to another partition". Retrieved March 12, 2015.
- ^ Hermann Schinagl (August 23, 2013). "ln - commandline hardlinks - Symbolic links for Windows XP".
- ^ "リンク/ジャンクション作成ツール". emk.name.
External links
[edit]- Documentation for NTFS symbolic links on MSDN
- CreateSymbolicLink function in the Win32 API
- fsutil hardlink create - creates a hard link (Windows 2000 and later)
- Microsoft Knowledge Base Article – 'How to Create and Manipulate NTFS Junction Points' (archived version)
- Junction command line utility from Microsoft TechNet
- Codeproject Article – discussion on the source code of a junction point utility, aimed at programmers
- PC Mag Article Archived 2008-12-11 at the Wayback Machine about adding any directory to the start menu (allowing a preview within the startmenu as a submenu).