An NTFS reparse point is a type of NTFS file system object. It is available with the NTFS v3.0 found in Windows 2000 or later versions. Reparse points provide a way to extend the NTFS filesystem. A reparse point contains a reparse tag and data that are interpreted by a filesystem filter driver identified by the tag. Microsoft includes several default tags including NTFS symbolic links, directory junction points, volume mount points and Unix domain sockets. Also, reparse points are used as placeholders for files moved by Windows 2000's Remote Storage Hierarchical Storage System. They also can act as hard links[citation needed], but are not limited to pointing to files on the same volume: they can point to directories on any local volume. The feature[which?] is inherited to ReFS.[1]
The open source NTFS-3G driver implements built-in support for the link-type reparse points, namely symbolic links and junction points. A plugin filter system is available to handle additional types of reparse points, allowing for chunk-deduplicated files, system-compressed files, and OneDrive files to be read.[2]
YouTube Encyclopedic
-
1/3Views:4041 2021 327
-
Symbolic link
-
ReFS
-
IBM Tivoli Storage Manager
Transcription
Structure
A reparse point has the following general structure, in C struct form:
struct REPARSE_BUFFER {
uint32_t ReparseTag;
uint32_t ReparseDataLength;
uint16_t Reserved;
uint8_t DataBuffer[]; // flexible array member
}
The reparse tag[3] is unique to each type of reparse point. It defines to which reparse point handler (usually a file system filter driver) the I/O manager delegates the processing.[4] Microsoft provides documentation on some "public" tag types.[5]
Types
Volume mount points
Volume mount points are similar to Unix mount points, where the root of another file system is attached to a directory. In NTFS, this allows additional file systems to be mounted without requiring a separate drive letter (such as C:
or D:
) for each.
Once a volume has been mounted on top of an existing directory of another volume, the contents previously listed in that directory become invisible and are replaced by the content of the root directory of the mounted volume.[citation needed] The mounted volume could still have its own drive letter assigned separately. The file system does not allow volumes to be mutually mounted on each other. Volume mount points can be made to be either persistent (remounted automatically after system reboot) or not persistent (must be manually remounted after reboot).[citation needed]
Mounted volumes may use other file systems than just NTFS, possibly with their own security settings and remapping of access rights according to the remote file system policy.
The substitute names of volume mount points use the NT namespace form \??\DeviceName\
.[6][7][4] Junctions generally use \??\<drive>:\
to refer to a volume with an existing driver letter, while true volume mount points use \??\Volume{<guid>}
to refer to any volume. UNC paths are invalid for junctions.[8]
Directory junctions
Directory junctions are defined using the exact same mechanism (and reparse tag: IO_REPARSE_TAG_MOUNT_POINT
) as volume mount points are. The only difference is that their substitute names point to a subdirectory of another volume that usually already has a drive letter. 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).[4]
For instance, the directory C:\exampledir
with a directory junction attribute that contains a link to D:\linkeddir
will automatically refer to the directory D:\linkeddir
when it is accessed by a user-mode application.[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. Unlinking a directory junction does not delete files in the target directory.
Some directory junctions are installed by default on Windows Vista, for compatibility with previous versions of Windows, such as Documents and Settings
in the root directory of the system drive, which links to the Users
physical directory in the root directory of the same volume. 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).[citation needed]
Symbolic links
Symbolic links (or soft links) were introduced in Windows Vista.[10] Symbolic links are resolved on the client side. So when a symbolic link is shared, the target is subject to the access restrictions on the client, and not the server.[citation needed]
Symbolic links can be created either to files (created with MKLINK symLink targetFilename
) or to directories (created with MKLINK /D symLinkD targetDirectory
), but (unlike Unix symbolic links) the semantic of the link must be provided with the created link. The target however need not exist or be available when the symbolic link is created: when the symbolic link will be accessed and the target will be checked for availability, NTFS will also check if it has the correct type (file or directory); it will return a not-found error if the existing target has the wrong type.[citation needed]
They can also reference shared directories on remote hosts or files and subdirectories within shared directories: their target is not mounted immediately at boot, but only temporarily on demand while opening them with the OpenFile()
or CreateFile()
API. 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).[citation needed]
The symbolic link data is similar to mount point data, in that both use an NT namespace path. The difference is that symbolic links accepts UNC paths, but not Volume{guid} mounts.[8]