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.
Compare with a typical Unix file system, where a hard link points to an inode.
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.
This means that the application accessing a link will be seamlessly redirected by the file system driver, and no special handling is needed.
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.
All versions of the Windows NT family can use GetFileInformationByHandle() to determine the number of hard links associated with a file.
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.
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, 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.
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.
The default security settings in Windows disallow non-elevated administrators and all non-administrators from creating symbolic links but not junctions.
It is technically possible to redirect the following non-critical system folder locations: 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.
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.
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.