Directory Entries#

Directory entries (type 0x30) are B+-tree rows within a per-directory B+-tree. Each file or subdirectory appears as a type 0x30 row in its parent directory’s tree. The storage mode (resident vs non-resident) determines the value layout, and a parser must resolve that mode from the key flags before reading any field.

B+-tree row header — 16 bytes#

Every row in a B+-tree leaf begins with this header:

See B+-Tree Node for the page-level node structure that holds these rows.

Key format (type 0x30)#

Key flags#

Only two key_flags values exist on disk (distribution {0x01, 0x02} only, zero occurrences of 0x04):

A directory is stored with key_flags 0x02 (the non-resident value layout) and is identified by the directory attribute bit 0x10000000 at value+0x40: RefsAddFileNameIndexEntry ORs the 0x10000000 bit into the attribute word. There is no separate 0x04 = directory flag.

The non-resident value length is 72 bytes on v3.4–v3.9 and 84 bytes on v3.10+ (measured across all corpus images) — the driver RefsAddFileNameIndexEntry sets local_a8 = 0x54 (84) for v3.10+ volumes and 0x48 (72) for older ones.

Resident file value (key_flags = 0x01) — variable size#

The resident value is an index entry that mirrors the file’s own type-0x10 $STANDARD_INFORMATION at every offset except 0x58/0x60, where it carries FileSize / AllocatedSize instead of the $SI’s (always-0) USN / DataSize fields. The own-row $SI total size is 116 bytes (0x74) on Win10 and 124 bytes (0x7C) on Win11. See Standard Information for that separate structure, and Resident Storage for the threshold that keeps a file inline.

Sub-record row count (offset 0x20 in resident value)#

The value+0x20 field is a count of embedded sub-record rows in the resident file’s inline B+-tree (the inline file object’s sub-record table: 1 default $DATA + one row per ADS, snapshot, reparse, EA, and $EFS). It is NOT a fixed 1-6 enum. It equals the parsed sub-record row count in the large majority of resident files (the residual are deleted/marker rows). The count is unbounded: values up to 14 have been observed (e.g. a file with 12 ADS).

The values below are common cases (consequences of the count), not an exhaustive enumeration:

Embedded sub-record markers#

Sub-records begin at offset 0xA8+ and form a chain. Single-instance sub-records carry one attribute each; multi-instance sub-records may appear multiple times for streams with the same descriptor.

ADS and snapshot sub-records (descriptor 0x000500B0)#

Both alternate data streams (ADS) and snapshot streams are stored as multi-instance sub-records with the same descriptor 0x000500B0. The StreamSummary.Flags field (u16) at the start of the StreamSummary region discriminates them: 0 = ADS, 2 = snapshot. See $SNAPSHOT for the value format.

Sub-record header (immediately after alignment):

Snapshot extent linking: When SS flags = 2, the entry is a snapshot stream (NOT an ADS). The stream_index at header+0x44 matches a 0x000E0080 (DATA) sub-record’s stream_index at sub_rec+0x08 within the same value, providing the extent table for the snapshot’s content. See $NAMED_DATA and $SNAPSHOT for the value format.

DATA sub-records (descriptor 0x000E0080)#

Extent tables for non-resident content are stored in multi-instance sub-records with descriptor 0x000E0080. Multiple DATA sub-records may coexist in one value (default $DATA, ADS streams, internal streams).

Non-resident file value (key_flags = 0x02) — 84 bytes (v3.10+) / 72 bytes (v3.4–v3.9)#

Directories also use this layout (key_flags 0x02) and are identified by the directory attribute bit 0x10000000 at offset 0x40.

Critical layout differences#

Timestamps and most fields are at different offsets between resident and non-resident entries:

A parser must resolve the storage mode from key_flags before reading any timestamp. Applying the wrong offset layout will misparse every field.

Hard links#

When a file gains a second name it is promoted to the non-resident layout above (key_flags 0x02), and each name becomes its own type-0x30 entry. All of one file’s names share value+0x00 (the per-directory child ordinal) and value+0x08 (the home-dir backref) — both already in the non-resident value table above. There is no explicit on-disk HardLinkCount field, and $SI+0x70 is a resident-layout scalar that always reads 1, so the link count is derived by resolving each name to its size-matched type-0x40 stream rather than read from a field. Hard links are a native v3.14 feature. See Hard Links for the full resolution model and forensic implications.

Reverse index (type 0x20)#

A directory’s tree also carries type 0x20 rows: a per-object FileId-resolution index that maps a child index back to either the object’s name (Format A) or its home-directory back-reference (Format B). Not every type 0x30 child has a corresponding type 0x20 row. The full key and value layouts are in Reverse Index.

Cross-references#

• Reverse Index – the type 0x20 FileId-resolution rows in the same directory tree
• Extent Descriptors – non-resident files link to type 0x40 extent rows
• Object Table – the home-dir backref in non-resident entries resolves via the Object Table
• Standard Information – $SI layout differs by version
• Resident Storage – threshold rules for resident vs non-resident
• Hard Links – multi-name files and the size-matched link count

Evidence#

The key/value layouts, the version size split (84/72 bytes), the {0x01, 0x02}-only key-flag census, the resident/non-resident field offsets, the sub-record markers and descriptors, and the 0 = ADS / 2 = snapshot discriminator are raw-disk decoded across the corpus and corroborated in the driver: RefsAddFileNameIndexEntry ORs the directory bit and gates the 84/72-byte length, RefsCreateStreamSnapshot sets the snapshot StreamSummary bit, and the hard-link identity pair is written by RefsLinkFileToSelf.