Reparse points & symlinks

File systems described directories and files as ordinary namespace entries. Some entries are deliberately not ordinary — they're tagged so that opening them triggers special handling before the request continues. That tag is a reparse point, and it's the single underlying mechanism behind several features that look, at first glance, unrelated.

One mechanism, marked with a tag

A file or directory can carry a reparse tag — a marker recorded in its file-system metadata, along with tag-specific data — that tells the I/O system "don't just resolve this normally; something needs to interpret it first." When an open request reaches an object carrying a reparse tag, the request is handed to whatever's registered to handle that specific tag: this might be the file system itself (for a symbolic link or junction), or it might be a filter driver sitting in the device stack (as covered in Drivers & device stacks) specifically designed to interpret that tag's data and redirect or synthesize the response.

The same mechanism, several very different uses

• Junctions (a form of directory-level reparse point) redirect a directory to another path, often on a different volume — opening anything under the junction transparently resolves against the target location instead.
• Symbolic links (files or directories) work similarly but with somewhat different semantics and can point at paths that don't yet exist, unlike a junction.
• Cloud-sync placeholder files (the mechanism behind "files on demand" style features) use reparse points to represent a file that exists in name and metadata locally, but whose actual content lives in the cloud and gets fetched on first access — the reparse point is what triggers that fetch transparently when something tries to open the file.

All three are, structurally, the exact same underlying primitive — a tagged object plus a registered handler — used for genuinely different purposes.

Symlinks are not hard links

A distinction worth being precise about, since the two are easy to conflate: a hard link is a second directory entry pointing at the same underlying file data (the same MFT entry, in NTFS terms) — there's no redirection involved at all; it's simply two names for one file, and deleting either name leaves the file intact as long as the other name still references it. A symbolic link, by contrast, is a reparse point: a genuinely separate file-system object whose entire content is "go look somewhere else," resolved dynamically every time it's opened. Deleting the target of a symlink leaves a broken link behind; deleting one name of a hard-linked file has no effect on the other name, because there was never a "target" being pointed at in the first place — just one piece of data with two names.

A worked example: what dir is actually telling you

Seeing <JUNCTION> or <SYMLINK> in a directory listing is the file system telling you, directly, that the entry you're looking at is a reparse point rather than an ordinary file or folder — the actual content (or, for a junction, the actual directory) lives somewhere else, and Windows is transparently redirecting anything that tries to access it. This matters for anything doing careful path-based analysis (backup tools, forensic investigation, security tooling): naively assuming every path is exactly what it appears to be can lead to either infinite redirection loops (poorly-handled recursive junctions) or subtly wrong conclusions about where data actually resides.

A common mistake

Treating every unusual directory-listing marker as "probably a shortcut" undersells how much real, load-bearing functionality — directory redirection for legacy compatibility, cross-volume mount points, and modern cloud-sync features — is built on exactly this one mechanism. Reparse points are infrastructure, not a niche convenience feature, and understanding them is often the difference between correctly interpreting a file system layout and being quietly misled by it.

Where this connects

• Drivers & device stacks covers the filter-driver mechanism that a cloud-sync client, for instance, typically uses to actually implement its reparse-tag handling.
• File systems covers the on-disk metadata model reparse tags are stored alongside.