It defines to which reparse point handler (usually a file system filter driver) the I/O manager delegates the processing.
In NTFS, this allows additional file systems to be mounted without requiring a separate drive letter (such as C: or D:) for each.
[8] Directory junctions are defined using the exact same mechanism (and reparse tag: IO_REPARSE_TAG_MOUNT_POINT) as volume mount points are.
This function is conceptually similar to symbolic links to directories in Unix, except that the target in NTFS must always be another directory (typical Unix file systems allow the target of a symbolic link to be any type of file).
[9] Directory junctions (which can be created with the command MKLINK /J junctionName targetDirectory and removed with RMDIR junctionName from a console prompt) are persistent, and resolved on the server side as they share the same security realm of the local system or domain on which the parent volume is mounted and the same security settings for its contents as the content of the target directory; however the junction itself may have distinct security settings.
However they are hidden by default, and their security settings are set up so that the Windows Explorer will refuse to open them from within the Shell or in most applications, except for the local built-in SYSTEM user or the local Administrators group (both user accounts are used by system software installers).
This additional security restriction has probably been made to avoid users of finding apparent duplicate files in the joined directories and deleting them by error, because the semantics of directory junctions are not the same as for hard links; the reference counting is not used on the target contents and not even on the referenced container itself.
[citation needed] Directory junctions are soft links (they will persist even if the target directory is removed), working as a limited form of symbolic links (with an additional restriction on the location of the target), but it is an optimized version allowing faster processing of the reparse point with which they are implemented, with less overhead than the newer NTFS symbolic links, and can be resolved on the server side (when they are found in remote shared directories).
So when a symbolic link is shared, the target is subject to the access restrictions on the client, and not the server.
Their definition is persistent on the NTFS volume where they are created (all types of symbolic links can be removed as if they were files, using DEL symLink from a command line prompt or batch).
The difference is that symbolic links accepts UNC paths, but not Volume{guid} mounts.
[11] Tracking is implemented as a system service, which uses the object identifier (OID) index stored in a metafile.
[citation needed] NSS was an ActiveX document storage technology that has since been discontinued by Microsoft.
[18] Internally, the compressed file is recorded as a reparse point with tag IO_REPARSE_TAG_WOF (0x80000017), where WoF stands for Windows Overlay Filter,[19] and the actual data is stored in an alternate data stream named "WofCompressedData", which is processed by WOF file system filter.