NTFS links

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

However it is possible to redirect non-critical folders:

• \Users
• \Documents and Settings
• \Program Files
• \Program Files (x86)

Creating junctions for \Users and \ProgramData pointing to another drive is not recommended as it breaks updates and Windows Store Apps.[3]

Creating junctions for \Users, \ProgramData, "\Program Files" or "\Program Files (x86)" pointing to other locations breaks installation or upgrade of Windows.[4]

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.

• Windows Component Store (WinSxS) use hard links to keep track of different versions of DLLs stored on the hard disk drive.
• Symlinks are in Windows Server 2008 for a \Users\All Users\ -> \ProgramData\ redirection (in basic installation).

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.

The contents of a junction use almost no disk space (they simply point to the original directory). If you need to have multiple points of entry to a large directory, junction points will serve that purpose well. 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.

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.

Significant hazards lurk in the use of hard links schemes that either:

• include links that refer to their own parent folders, such as creating hard link X:\path\to\parent which points to either X:\path\ or X:\path\to\, or
• specify targets by using volume drive letters, such as X:, in X:\some\path\.

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.

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 an 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,[5] 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.

On all versions of Windows that support them, hard links and symlinks can be safely deleted like normal files are. However, when asked to delete a junction, Windows explorer pre-Windows Vista will follow the directory and delete all its contents with it.

To correctly remove the junction only, one can use the rmdir command in CMD from Windows Vista or later. Alternatively one can use the fsutil reparsepoint delete command in fsutil.[12] Windows PowerShell had a similar problem with junctions.[13]

On the API level, junctions and symlinks, even those pointing to directories, can be removed with pNtSetInformationFile. Libuv's implementation of unlink on Windows demonstrates this use.[14] Alternatively, the .NET System.IO.Directory::Delete method works on them as well.[13]

A list of all the junctions present in the current directory can be obtained from an elevated Command Prompt as Admin by executing dir /aL, and a list of all the junctions present on a disk volume, by executing dir /aL /s C:\, where "C:" is the volume to scan.