$REPARSE_POINT#

$REPARSE_POINT stores the inline REPARSE_DATA_BUFFER for a reparse point — a symlink, junction, mount point, or WSL special file (embedded type 0xC0, schema 0x1C0; the v3.7+ “v2” format). It appears as a single-instance sub-record inside a file’s type-0x10 own-row and inside resident type-0x30 directory entries. The reparse tag is also mirrored into $STANDARD_INFORMATION at $SI+0x54.

Value layout#

Sub-record: marker 0x80000001 (single-instance), type code 0x00C0, subtype 0x0000.

Value:

Symlink (tag 0xA000000C):

Mount point / junction (tag 0xA0000003): the same layout without the 4-byte Flags field — the path strings begin at 0x1C.

Value sizes range roughly 188–548 bytes, depending on the path-string length.

Where to find it on a directory#

On a file, the buffer is usually reachable from a top-level 0xC0 attribute row. On a directory reparse point — a junction or a directory symlink — it is not: the directory’s own table holds a single row keyed 0x10, and the buffer sits in the attribute tree embedded in that row’s value, alongside the 0x90 and 0x39 attributes. The name row in the parent directory is an 84-byte index entry with no room for it. A reader that looks only at top-level rows therefore finds nothing and reports the target as absent, though it is fully present: across the image corpus 98 of 341 reparse-bearing objects keep their buffer only there — 78 of 81 on a real Windows volume, where they are the familiar compatibility junctions (\??\C:\ProgramData, \??\C:\Users\Default, Program Files, …).

Two decode consequences follow. A junction commonly carries print name length 0, so the substitute name is the authoritative target — never fall back to the tag’s name. And if the object’s attribute set is large enough that its embedded tree becomes an index node, the attributes live one level further down again (see Attributes), so the descent has to be followed there too.

Reparse tags#

refs.sys structurally recognizes only two tags: 0xA0000003 (junction — gated to directory targets) and 0xA000000C (symlink — gated on privilege / redirection-trust level). Every other tag is stored verbatim with no interpretation — WSL, WCI, WOF, and dedup tag handling lives entirely in minifilters, not in refs.sys.

WSL special files#

WSL records a special file in two separate mechanisms — only one of which is a reparse point:

• The special-file type (FIFO, socket, character/block device, Linux symlink) is a reparse point, using the LX_* / AF_UNIX tags above. The payload format is defined by the WslFs minifilter; for a FIFO the payload is empty (the tag alone marks the type).
• The Linux ownership and mode ($LXUID / $LXGID / $LXMOD / $LXDEV) are extended attributes, not reparse data — see $EA_INFORMATION and $EA. They require a WSL -o metadata mount.

So a WSL device node carries both: a reparse point (the LX_CHR / LX_BLK tag) and an $EA chain ($LXMOD carrying the S_IFMT type bits, $LXDEV carrying the major:minor numbers).

Cross-references#

• $STANDARD_INFORMATION — the reparse tag is mirrored at $SI+0x54
• $EA_INFORMATION and $EA — the WSL $LX* ownership/mode EAs
• Directory Entries — the embedded sub-record location
• WSL / Linux Metadata — the full WSL artifact picture

Evidence#

Type 0xC0 / schema 0x1C0 and the value layout are confirmed in the decompiled driver and raw-disk decoded across the corpus; the recognize-vs-store-verbatim behavior is from the driver’s reparse handling (only 0xA0000003 / 0xA000000C are interpreted). Also registered for statements on this page:.