On NTFS, how do a directory junction, a symbolic link, and a hard link differ?

## Reparse points: the shared mechanism NTFS supports *reparse points* — a directory entry can carry a reparse tag plus a blob of tag-specific data. When the I/O manager walks a path and hits one, the filesystem returns a status telling the caller "this is not the end of the road", and a registered filter interprets the blob. Junctions, symbolic links and volume mount points are all built on this one mechanism, distinguished by their tag: `IO_REPARSE_TAG_MOUNT_POINT` for junctions and mount points, `IO_REPARSE_TAG_SYMLINK` for symbolic links. Hard links are *not* reparse points and belong to a different layer entirely — which is the first thing to say when an interviewer lumps all three together. ## Hard link A hard link is an additional filename in a directory that references the same MFT record as an existing name. Consequences: - Neither name is the "original"; they are peers, sharing content, size, ACL and timestamps, because there is only one file. - The file's data is released when the last name referencing the record is removed — NTFS keeps a link count exactly as Unix does. - Both names must live on the same volume, since an MFT is per-volume. - Directories cannot be hard-linked, which prevents cycles in the tree. Because both names are the same object, editing through one is visible through the other — but a program that saves by writing a temp file and renaming over the target *breaks* the link, leaving the other name pointing at the old content. That is the classic hard-link surprise, on Windows and Unix alike. ## Junction A junction ("directory junction", "soft link" in older docs) redirects a directory to another directory. Key properties: - **Directories only.** You cannot junction a file. - **Absolute local target.** The stored path is absolute and must be a local volume path; junctions cannot point at UNC shares. - **Resolved where the volume lives.** If a client opens a path over SMB and hits a junction on the server, the server resolves it against its own filesystem. A path that resolves fine locally can therefore mean something different, or fail, remotely. - **No special privilege** to create. - The target is not validated at creation, so a junction can dangle. Windows itself ships junctions for backwards compatibility — the legacy `C:\Documents and Settings` name, and the per-user compatibility entries under a profile, are junctions, deliberately ACL'd to deny listing so that recursive tools do not loop through them. ## Symbolic link A symbolic link stores a target path and is resolved by the *client* of the path. It is the closest analogue to a Unix symlink: - Can target a file or a directory, and the two are distinguished at creation time (`mklink` for a file, `mklink /D` for a directory) — get it wrong and the link misbehaves. - Can be **relative**, which junctions cannot, so a tree of relative symlinks survives being moved. - Can name a **UNC path**, so it can point across the network. - Requires `SeCreateSymbolicLinkPrivilege`, held by Administrators by default. Since Windows 10 version 1703, enabling Developer Mode lets an unelevated process create one by passing the unprivileged-create flag to `CreateSymbolicLinkW`. This privilege gate is why tooling ported from Unix often fails on Windows until the developer elevates or turns Developer Mode on. ## Volume mount points The same mount-point tag also lets a whole volume be grafted onto an empty NTFS directory instead of consuming a drive letter — created with `mountvol` or the Disk Management UI. It is how a server exposes twenty volumes without running out of letters, and it is why a directory can suddenly have completely different free space than its parent. ## Where each one bites you - **Backup and recursive tools.** A tool that follows reparse points can traverse the same data repeatedly or escape the tree it was told to copy. Well-behaved tools skip reparse points or copy the link itself. - **Disk usage.** Hard-linked files are counted once by the filesystem but often multiple times by tools that sum file sizes, which makes "the folder sizes add up to more than the disk" a common confusion. - **Cross-machine paths.** Junctions resolving server-side versus symlinks resolving client-side is the distinction that decides whether a shared path works over SMB. - **Privilege.** Build systems, package managers and version-control checkouts that create symlinks are the usual reason a developer machine needs Developer Mode. ``` mklink /J C:\app\current C:\app\releases\v42 mklink /D C:\app\shared \\fileserver\shared mklink /H C:\app\copy.dll C:\app\lib.dll ``` If you remember one sentence: hard links are another name for the same file, junctions are a local directory-only redirect resolved by the volume's owner, and symbolic links are a general path redirect resolved by whoever walks the path — and only the last one is privileged.