reference_table.csv

ref_id,category,structure,description,source,page,refs_version,verified_on,confidence,verification_target,static_analysis_status,static_analysis_notes,raw_analysis_status,raw_analysis_notes,static_evidence_level,static_evidence,static_scope,disk_examined,disk_status,origin,format_claimed,format_verified,status_basis
GN_ARCH_001,General,Architecture,ReFS uses Minstore B+ tree storage engine,WININT;PRADE-TR,pp.25-33,General,3.4;3.14,High,No,CONFIRMED,PDB symbols show CmsBPlusTable (186 funcs Win10 / 160 Win11); all metadata stored as key-value pairs in B+-trees,CONFIRMED,All 39 images show MSB+ signature on every metadata page; B+-tree walking confirmed across all table types,E2,E2,all,yes,CONFIRMED,prior_work,,3.4;3.14,
GN_ARCH_002,General,Architecture,Copy-on-Write / Allocate-on-Write update policy,WININT;PRADE-TR;LEE-JRN,p.9;p.5,General,3.4;3.14,High,No,CONFIRMED,CoW propagation visible in MsUpdateDataWithRoot and CmsCowRootComposite class; old pages never overwritten; checkpoint = atomic commit point,CONFIRMED,Virtual clock increments at each checkpoint confirm CoW model; old pages visible in log data area scans,E2,E2,all,yes,CONFIRMED,prior_work,,3.4;3.14,
GN_ARCH_003,General,Architecture,Virtual addressing with Container Table translation (v2+),PRADE-TR;LEE-JRN,pp.39-41;p.3,3.4,3.4;3.14,High,Yes,CONFIRMED,CmsVolumeContainer class (72 funcs Win10 / 130 Win11) manages container-level operations; translation formula confirmed in CmsStream extent resolution,CONFIRMED,"Translation formula verified: PLCN = map[VLCN >> shift] + (VLCN & mask). Tested on 39 images, all configurations",E2,E2,all,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
GN_ARCH_004,General,Architecture,"Metadata checksums: None (3.4), CRC64 (3.14 default), SHA256 (optional). User data checksums: opt-in via integrity streams",WININT;NORDVIK;REFUZZ,p.128,General,3.4;3.14,High,No,ENRICHED,Win10: 56 CRC template specializations (CmsCrc32/CmsCrc64) + CmsChecksumNone(8) — but CmsChecksumNone::VerifyChecksum always returns TRUE (no actual verification). Win11: unified CmsChecksum(11) delegates to SymCrypt. CmsIntegrityState (17/66 funcs). Literature claim 'always on metadata' CORRECTED: no metadata checksums on 3.4. Merged from GN_CHKS_SA_001 and GN_MISC_008,ENRICHED,"VBR 0x2A selector: 0=None(3.4), 2=CRC64(3.14), 4=SHA256. Win10 CONFIRMED no metadata checksums (fsutil: CHECKSUM_TYPE_NONE, CHKP bit 0x400 not set). Upgraded 3.4→3.14 gains CRC64 at CHKP level despite VBR 0x2A remaining 0x00. See report_checksum_investigation.md",E2,E2,,yes,CONFIRMED,prior_work,,3.4;3.14,"dossier GN_ARCH_004.md: Re-verification verdict CONFIRMED-ALLDISK — VBR 0x2A selector 0=None/2=CRC64/4=SHA256, 4 on 4 SHA images"
GN_ARCH_005,General,Architecture,Pages (1-4 clusters) with header: signature+clock+address,PRADE-TR;LEE-JRN,pp.23-24;p.2,3.4,3.4,High,No,CONFIRMED,All five page signatures (FSRS/SUPB/CHKP/MSB+/MLog) confirmed as ASCII string literals in both binaries,CONFIRMED,"All 5 signatures observed in raw disk data: FSRS(VBR), SUPB(superblock), CHKP(checkpoint), MSB+(B+tree), MLog(log)",E1 (all),E1,all,yes,CONFIRMED,prior_work,3.4,3.4,
GN_PAGE_001,General,Page Header,0x00-0x04: page signature (SUPB/CHKP/MSB+),PRADE-TR,p.50,3.4,3.4;3.14,High,No,CONFIRMED,Signatures found in binary string table of both Win10 and Win11 refs.sys,CONFIRMED,Validated on all 39 images; every metadata page starts with 4-byte ASCII signature,E1,E1,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
GN_PAGE_002,General,Page Header,0x04-0x08: constant 0x2,PRADE-TR,p.50,3.4,3.4;3.14,High,No,CONFIRMED,Raw disk analysis: verified as 0x00000002 on all 39 images (filesystem_category.md Section 10.1),CONFIRMED,Observed value 0x2 at offset 0x04 in all MSB+ pages across all images,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
GN_PAGE_003,General,Page Header,0x0C-0x10: volume signature,PRADE-TR,p.50,3.4,3.4;3.14,High,No,CONFIRMED,"STATIC: CalculateVolumeSignature is present and byte-identical in all six builds - win10 17134 @1c0068a88, 26100.8115 @1400f54b0, .8521 @1400f54c0, .8972 @1400f47e0, .9444 @1400f4b60, insider 29574 @14011b18c - each computing uVar1 = u32@+0x0C ^ u32@+0x08 ^ u32@+0x04 ^ u32@+0x00 over the volume GUID at SUPB+0x50, and mapping a result of 0 to 1. The 0 -> 1 substitution is part of the algorithm and must be stated wherever the XOR is. (This note previously carried a disk measurement under a static CONFIRMED status with no driver citation at all.)",CONFIRMED,XOR of volume GUID dwords; verified on all 39 images (filesystem_category.md Section 2.3),N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
GN_PAGE_004,General,Page Header,0x10-0x18: virtual allocator clock,PRADE-TR,p.50,3.4,3.4,High,No,CONFIRMED,Raw disk analysis: allocator clock values range 23-7295 across images; confirmed present on all page headers,INFERRED,"Virtual clock read from CHKP offset 0x10; values match between checkpoint and page headers | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): Offset/presence confirmed. The 'allocator virtual clock' SEMANTIC (vs tree-update clock at 0x18) is E2/CHKP-correlated; the two 8-byte counters at 0x10 and 0x18 both exist on disk but distinguishing which is allocator vs tree cloc",N/A,NONE,,no,INFERRED,prior_work,3.4,3.4,
GN_PAGE_005,General,Page Header,0x18-0x20: tree update clock,PRADE-TR,p.50,3.4,3.4,High,No,CONFIRMED,Raw disk analysis: tree update clock observed on all MSB+ pages; matches Prade's description,INFERRED,"8-byte per-tree modification counter. Non-zero in 82% of pages (343/420 in 4GB image). Distinct from VA clock at 0x10 | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): Field at 0x18 confirmed on disk; 'tree update clock' label is E2/inference. Offset CONFIRMED, semantic INFERRED.",N/A,NONE,,no,INFERRED,prior_work,3.4,3.4,
GN_PAGE_006,General,Page Header,0x20-0x40: page address LCN quadruple,PRADE-TR,p.50,3.4,3.4,High,No,CONFIRMED,"Raw disk analysis: 4x u64 LCN values confirmed on all pages; format [LCN,LCN,0,0] for non-mirrored",CONFIRMED,LCN quadruples observed in all page headers; up to 4 LCNs for multi-cluster pages,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
GN_PAGE_007,General,Page Header,0x40-0x50: table identifier (high+low),PRADE-TR,p.50,3.4,3.4,High,No,CONFIRMED,"E2 2026-06-18: FormatPageHeaderInternal writes page+0x40=id+0x178 (TableIdHigh), page+0x48=id+0x180 (TableIdLow); MsInitializeWellKnownObjectId builds the 16-byte _SmsBigIdentifier as {high=0, low=numeric OID}. Driver compares the LOW half (0x48); TableIds per A.4 (Object ID Table=0x02, Block Refcount=0x05, system tables 0x01-0x22) — E52. page+0x40 is the OID HIGH half (always 0), NOT a schema field. v3.4+v3.14.",CONFIRMED,"RE-MEASURED ALL-DISK 2026-06-18: page+0x40==0 on 137,444/137,444 MSB+ pages (all versions/cluster sizes + SUPB/CHKP); numeric table OID at 0x48. The '0x40-0x50 = table identifier high+low' framing is CONFIRMED (16-byte OID); the earlier 'low=schema type' note was wrong. Resolves the NEEDS-STATIC hold. See structure_reference A.2.",E2,E2,all,yes,CONFIRMED,prior_work,3.4,3.4,
GN_PREF_001,General,Page Reference,0x00-0x20: referenced page LCN quadruple,PRADE-TR,p.51,3.4,3.14,High,No,CONFIRMED,Raw disk analysis: page references parsed in CHKP root pointers (both 104-byte and 48-byte formats),CONFIRMED,Root references in CHKP contain LCN quadruples; size varies: 0x68(3.4) vs 0x30(3.14/CRC64) vs 0x48(SHA256),N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.14,
GN_PREF_002,General,Page Reference,"0x22-0x23: checksum type (1=CRC32-C, 2=CRC64 [custom poly, NOT ECMA-182, #326])",PRADE-TR,p.51,3.4,3.4,High,Yes,ENRICHED,Win10 had CmsCrc32 (multiple template variants) and CmsCrc64 variants; Win11 replaced all with unified CmsChecksum class delegating to SymCrypt,ENRICHED,"VBR 0x2A is the selector: 0=None, 2=CRC64, 4=SHA256. Reference size changes accordingly: 0x68/0x30/0x48",E2,E2,,yes,CONFIRMED,prior_work,3.4,3.4,dossier GN_PREF_002.md: Re-verification verdict CONFIRMED-ALLDISK — self-checksum cktype 1=CRC32-C(4K)/2=CRC64(64K)/4=SHA256 recomputed
GN_PREF_003,General,Page Reference,0x24-0x26: checksum length,PRADE-TR,p.51,3.4,not_verified,High,No,CONFIRMED,verify_static.py: decompiled code / function catalog evidence,CONFIRMED,PT: CRC64 ref checksum length at 0x24 = 8 (verified on win11refsmini v3.14),N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.14,"format_verified 3.14 recovered 2026-09-09 from the row's own note: ""CRC64 ref checksum length at 0x24 = 8 (verified on win11refsmini v3.14)"" -- verified_on said not_verified, which the note contradicts"
GN_IDXR_001,General,Index Root,Root 0x00-0x04: size of index root,PRADE-TR,p.57,3.4,3.4,High,No,CONFIRMED,E2 2026-06-19: _SmsIndexRoot descriptor at page+0x50; size 0x28 at desc+0x04 (CreateIndex win10 @73080).,CONFIRMED,RD all-disk: desc+0x04=0x28 on all table-root pages (113 images). The descriptor is the structure Prade calls Index Root. See structure_reference A.2b.,E2,E2,,yes,CONFIRMED,prior_work,3.4,3.4,
GN_IDXR_002,General,Index Root,Root 0x0C-0x0E: schema of table,PRADE-TR,p.57,3.4,3.4,High,No,CONFIRMED,E2 2026-06-19: _SmsIndexRoot+0x0C = table SCHEMA id (CreateIndex win10 @73106 from RegisterSchema @17820; validated @73234; MsGetTableInfoFromTable win11 @196519).,CONFIRMED,"CONFIRMED ALL-DISK 2026-06-19: desc+0x0C (page+0x50+0x0C) is a valid schema id (0xe0c0 CT, 0xe030 OT, 0x130 dir, ...) on 34,203/34,207 tables. PRADE CORRECT. The audit-2 INFERRED 'not a schema' read the per-node header thoff+0x0C (node-type) - the wrong structure. See structure_reference A.2b. Was INFERRED.",E2,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4,3.4,
GN_IDXR_003,General,Index Root,Root 0x18-0x20: number of extents,PRADE-TR,p.57,3.4,not_verified,High,No,CONFIRMED,E2 2026-06-19: _SmsIndexRoot+0x18 (u64) = table EXTENT/leaf-page count (CreateIndex win10 @73244 -> this+0x40; write-back CopyStateToTreeUpdateGen @82621; MsGetTableRowAndPageCount win11 @196550).,CONFIRMED,"CONFIRMED ALL-DISK 2026-06-19: desc+0x18 = number of leaf extents/pages (0 single-page; == leaf-page census on every clean multi-level table: oid7=10, oid73f=3, oid760=1). PRADE 'number of extents' CORRECT. See structure_reference A.2b. (Was NEEDS-STATIC in re-verify.)",E2,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4,unknown,
GN_IDXR_004,General,Index Root,Root 0x20-0x28: number of rows,PRADE-TR,p.57,3.4,3.4,High,No,CONFIRMED,"E2 2026-06-19: _SmsIndexRoot+0x20 (u64) = TOTAL row count of the whole table, incremented per row insert (EnqueueTreeUpdate this+0x38; CreateIndex win10 @73243; write-back @82620).",CONFIRMED,"CORRECTED 2026-06-19 (FRAME ERROR REVERSED, was CONTRADICTED): Prade's '0x20-0x28 = number of rows' is CORRECT - it is the _SmsIndexRoot descriptor (page+0x50) +0x20 = whole-table row count. RD: desc+0x20 == independent leaf-walk total on 34,177/34,207 tables, diverging from the per-node _SmsIndexHeader+0x14 on multi-level trees (387 vs 10 children; 245,759 vs 2). The 2026-06-18 'CONTRADICTED / count at thoff+0x14' analysed the per-node NODE header (wrong frame). See errata E49, structure_reference A.2b.",E2,E2,,yes,CONFIRMED,prior_work,3.4,3.4,
GN_IDXH_001,General,Index Header,0x00-0x04: offset to data area start,PRADE-TR,p.57,3.4,3.4;3.14,High,No,CONFIRMED,Raw disk analysis: data_start field parsed on all MSB+ pages (filesystem_category.md Section 10.3),CONFIRMED,B+-tree walker reads data area offset from page header+0x50; confirmed working on all images,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
GN_IDXH_002,General,Index Header,0x0C-0x0D: height of node,PRADE-TR,p.57,3.4,not_verified,High,No,CONFIRMED,verify_static.py: decompiled code / function catalog evidence,ENRICHED,PT: Page 0x0C is volume signature (not height). Table header thoff+0x0C contains inner/leaf flag (bit 0x100). Height encoding needs correction.,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,unknown,dossier GN_IDXH_002.md: Re-verification verdict CONFIRMED — **Original audit verdict:** CONFIRMED  (disk held 112/112 at audit time)  ·  **Registry status:** ENRICHED  ·  **Evidenc
GN_IDXH_003,General,Index Header,"0x0D-0x0E: flags (0x1 inner, 0x2 root, 0x4 stream)",PRADE-TR,p.57,3.4,3.4,High,No,CONFIRMED,verify_static.py: decompiled code / function catalog evidence,CONFIRMED,Inner node flag (0x100 in our encoding at trailer[3]) distinguishes internal from leaf nodes; confirmed by B+-tree walking,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
GN_IENT_001,General,Index Entry,0x00-0x04: entry length,PRADE-TR,p.58,3.4,3.4,High,No,CONFIRMED,Raw disk analysis: entry length parsed on all B+-tree rows; 16-byte header confirmed (GN_BPT_RA_001),CONFIRMED,Entry parsing confirmed across all tools; entry length used for row traversal,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
GN_IENT_002,General,Index Entry,0x04-0x06: key offset,PRADE-TR,p.58,3.4,3.4,High,No,CONFIRMED,Raw disk analysis: key offset used for key extraction on all tables,CONFIRMED,Key offset at position 1 in row header struct; used by all B+-tree parsers,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
GN_IENT_003,General,Index Entry,0x06-0x08: key length,PRADE-TR,p.58,3.4,3.4;3.14,High,No,CONFIRMED,Raw disk analysis: key length verified against actual key data on all tables,CONFIRMED,Key length at position 2; validated by successful key extraction across all images,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
GN_IENT_004,General,Index Entry,0x08-0x0A: flags (0x4 deleted),PRADE-TR,p.58,3.4,not_verified,High,No,ENRICHED,Deletion flag confirmed: RefsCommonCleanup removes B+-tree rows but CoW means old pages with deleted entries persist | SA reconciled 2026-06-20: verify_static evidence is co-occurrence/cited only (NOT function-scoped) after the >=3-regex gate fix; overall verdict rests on the raw_analysis (RD) column.,INFERRED,"PT: Row descriptor flags at +4. Deletion flag 0x4 confirmed via Ghidra (RefsCommonCleanup) | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): Offset/field at 0x08 confirmed on disk. The specific 0x04=deleted semantic is E2/Ghidra-derived (RefsCommonCleanup) and not observable in live pages (deleted rows are pruned via CoW); cannot be disk-confirmed without a torn/old Co",N/A,NONE,all,no,INFERRED,prior_work,3.4,unknown,
GN_IENT_005,General,Index Entry,0x0A-0x0C: value offset,PRADE-TR,p.58,3.4,3.4,High,No,CONFIRMED,Raw disk analysis: value offset used for value extraction on all tables,CONFIRMED,Value offset at position 4; used for value extraction in all tools,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
GN_IENT_006,General,Index Entry,0x0C-0x0E: value length,PRADE-TR,p.58,3.4,3.4,High,No,CONFIRMED,Raw disk analysis: value length verified against actual value data on all tables,CONFIRMED,Value length at position 5; validated by successful parsing of all table types,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
FS_VBR_001,File System,VBR,0x00-0x03: reserved jump instruction (zeros),PRADE-TR,p.48,3.4,3.4;3.14,High,No,CONFIRMED,RefsIsBootSectorOurs (present in all 3 builds: Win10/Win11/Insider) confirms these bytes are skipped; validation starts at offset 0x03,CONFIRMED,All 39 images show zeros at bytes 0-2 of VBR,E2 (all),E2,all,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_VBR_002,File System,VBR,0x03-0x0B: FSRS signature 'ReFS',PRADE-TR,p.48,3.4,3.4,High,No,CONFIRMED,RefsIsBootSectorOurs checks memcmp at offset 0x03 for 'ReFS' (0x52 0x65 0x46 0x53),CONFIRMED,refs_boot.py validates 'ReFS' at offset 0x03 on all valid images,E2,E2,all,yes,CONFIRMED,prior_work,3.4,3.4,
FS_VBR_003,File System,VBR,0x10-0x14: FSRS identifier 'FSRS',PRADE-TR,p.48,3.4,3.4,High,No,CONFIRMED,Insider decompilation shows validation starts with ReFS sig at 0x03; FSRS at 0x10 not explicitly checked in RefsIsBootSectorOurs,CONFIRMED,'FSRS' signature confirmed at offset 0x10 in all valid images by refs_boot.py,E2 (insider),E2,insider,yes,CONFIRMED,prior_work,3.4,3.4,
FS_VBR_004,File System,VBR,0x14-0x16: VBR size 0x200,PRADE-TR,p.48,3.4,3.4;3.14,High,No,ENRICHED,All builds: offset 0x14 is structure size field (ushort); must be > 0x57 and <= sector_size. Value 0x200 = 512 bytes confirms Prade,CONFIRMED,Value 0x200 observed in all images,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_VBR_005,File System,VBR,0x16-0x18: checksum for boot sector,PRADE-TR,p.48,3.4,3.4;3.14,High,No,CONFIRMED,All builds: rolling 16-bit checksum with rotate-left-1 + add; computed over bytes 3..size; skips checksum field itself at 0x16-0x17,CONFIRMED,refs_boot.py validates checksum on all 39 images; all pass,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_VBR_006,File System,VBR,0x18-0x20: sector count (volume size),PRADE-TR,p.49,3.4,3.4;3.14,High,No,CONFIRMED,All builds: uint64 at 0x18; validated as != 0; stored in VCB+0x1F0,CONFIRMED,Sector count matches file size / sector_size across all images,E2 (all),E2,all,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_VBR_007,File System,VBR,0x20-0x24: bytes per sector (0x200),PRADE-TR,p.49,3.4,3.4;3.14,High,No,CONFIRMED,All builds: uint32 at 0x20; validated range 0x200-0x1000; stored in VCB+0x114,CONFIRMED,All images show 0x200 (512 bytes per sector),E2 (all),E2,all,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_VBR_008,File System,VBR,0x24-0x28: sectors per cluster,PRADE-TR,p.49,3.4,3.4,High,No,ENRICHED,All builds: called 'cluster factor'; validated as 0x80/0x100/0x200 (64/128/256 KiB). Cluster size = factor * sector_size stored in VCB+0x110,CONFIRMED,Values 0x08 (4K clusters) and 0x80 (64K clusters) observed; matches cluster_size/sector_size,E2 (all),E2,all,yes,CONFIRMED,prior_work,3.4,3.4,
FS_VBR_009,File System,VBR,0x28 = major (u8) / 0x29 = minor (u8) ReFS version — two bytes NOT a LE u16,PRADE-TR;NORDVIK,p.49;p.131,3.4,3.4;3.14,High,No,CONFIRMED,All builds: byte@0x28=major byte@0x29=minor (2x u8; a LE u16 read gives the swapped 0x0e03 trap); stored in VCB+0x318,CONFIRMED,3.4 on all Win10 images; 3.14 on all Win11 and upgraded images; disk-verified 2026-07-30,E2 (all),E2,all,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_VBR_010,File System,VBR,0x38-0x40: volume serial number,PRADE-TR,p.49,3.4,3.4,High,No,CONFIRMED,All builds: uint64+ at 0x38 is Volume GUID; stored in VCB+0x1F8,CONFIRMED,Unique GUID per volume; preserved across upgrade (win10to11refs4g),E2 (all),E2,all,yes,CONFIRMED,prior_work,3.4,3.4,
FS_VBR_011,File System,VBR,0x40-0x48: bytes per container,PRADE-TR,p.49,3.4,3.4;3.14,High,No,CONFIRMED,Raw disk analysis: 0x04000000 (64 MiB) at offset 0x40 confirmed on all 39 images; invariant constant,CONFIRMED,Always 0x4000000 (64 MiB) across all 39 images regardless of cluster size,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_VBR_012,File System,VBR,"0x2A-0x37: 14 bytes unknown in Nordvik/Prade. 0x2A=checksum algo selector, 0x2B=reserved, 0x2C-0x2F=volume flags (0x06 Win10 / 0x66 Win11), 0x30-0x37=reserved",NORDVIK,p.131,3.2/3.4,3.4;3.14;insider,High,Yes,ENRICHED,All builds: 0x2A=checksum algorithm selector (1 byte; insider calls it 'boot option'); 0x2C=volume flags (4 bytes; insider names bits 5-6 'boot behavior'). Cluster factor validated as 0x80/0x100/0x200. Merged from FS_VBR_SA_001 (cross-build static analysis),CONTRADICTED,"VBR+0x2A is the checksum-algorithm selector, but the value is only CONSULTED when volume-flag bit 0x40 (VBR+0x2C) is set: InitializeVcbFromBootSector initialises the type to 2 and overrides it from the boot sector only under that gate (refs_win11.decomp.c:487460 'bVar6 = 2;', :487473-475 'if ((*(uint *)(param_3 + 0x2c) & 0x40) != 0) { bVar6 = *(byte *)(param_3 + 0x2a); }', then VCB+0x31c = bVar6; the same three lines in insider at 531289-531293). The v3.4 driver never reads VBR+0x2a in that function at all. So '0 = None' does not describe a v3.4 volume: win10refsmini has VBR 0x2A = 0x00 and VBR 0x2C = 0x06 (bit 0x40 CLEAR) yet its metadata is fully checksummed - integrity --checksums verifies 17 of 17 page references as CRC64 with 0 mismatches and recomputes 13 of 13 root-table pages to their stored CRC64, and the CHKP self-descriptor is cktype 1 (CRC32-C) and verifies. Read the page-reference form (CHKP+0x5C) for what is actually in use, not VBR+0x2A alone.",E2 (all),E2,all,yes,CONTRADICTED,prior_work,3.2;3.4,3.4;3.14,
FS_VBR_013,File System,VBR,Backup boot sector in last sector of volume,PRADE-TR;GEORGES,p.48,3.4,3.4,High,No,CONFIRMED,"All builds: ReadBootSectorForMount tries sector 0 first, falls back to last sector of volume",NOT_TESTED,,E2 (all),E2,all,no,NOT_TESTED,prior_work,3.4,3.4,
FS_SUPB_001,File System,Superblock,Located at cluster 0x1E (30),PRADE-TR,p.52,3.4,3.4;3.14,High,No,CONFIRMED,Superblock location is a fixed constant; not directly visible in decompilation but consistent with mount code flow,CONFIRMED,SUPB found at partition_start + 30*cluster_size in all 39 images,E2,E2,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_SUPB_002,File System,Superblock,0x50-0x60: volume GUID,PRADE-TR,p.52,3.4,3.4,High,No,CONFIRMED,Raw disk analysis: 16-byte GUID at SUPB+0x50 confirmed; XOR-folded to page header vol_sig (filesystem_category.md Section 2.3),CONFIRMED,Volume GUID extracted from SUPB+0x50; matches VBR GUID; preserved across version upgrade,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
FS_SUPB_003,File System,Superblock,0x68-0x70: superblock version/recency,PRADE-TR,p.52,3.4,3.4;3.14,High,No,CONFIRMED,Raw disk analysis: always value 1 across all 39 images,CONFIRMED,Version field always reads 1 across all images (both 3.4 and 3.14),N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_SUPB_004,File System,Superblock,0x70-0x74: offset to checkpoint references,PRADE-TR,p.52,3.4,3.4,High,No,CONFIRMED,Raw disk analysis: always 0xC0 across all 39 images,CONFIRMED,Offset consistently at 0x70; points to checkpoint reference array,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
FS_SUPB_005,File System,Superblock,0x74-0x78: number of checkpoint refs (typically 2),PRADE-TR,p.52,3.4,3.4;3.14,High,No,CONFIRMED,Alternating A/B checkpoint scheme confirmed via CmsVolume checkpoint code; recovery picks highest sequence number,CONFIRMED,Always 2 checkpoint references in all 39 images,E2,E2,all,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_SUPB_006,File System,Superblock,0x78-0x7C: self-descriptor offset/length,PRADE-TR,p.52,3.4,3.4,High,No,CONFIRMED,verify_static.py: decompiled code / function catalog evidence,CONFIRMED,Offset=0xD0 length=0x30 (48 bytes for CRC64 mode). Contains self-referencing page reference to LCN 0x1E,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
FS_SUPB_007,File System,Superblock,Two backup copies near end of partition,PRADE-TR,p.52,3.4,3.4;3.7;3.9;3.10;3.14;3.15,Medium,Yes,CONFIRMED,verify_static.py: decompiled code / function catalog evidence,CONFIRMED,"2 backups at LCN total_clusters-2 and total_clusters-3 (RE-MEASURED 2026-06-18, SUPB signature found at delta 2 AND 3 on 113/113 images; the earlier '-14339/-14338' was wrong). Identical GUID/chkp refs to primary. RE-CONFIRMED 2026-09-19 on the current corpus: backups at end_lcn-3 and end_lcn-2 on 102/102 ReFS volumes across v3.4(9) v3.7(1) v3.9(2) v3.10(2) v3.14(85) v3.15(1) and the two hand-edited v6.66 test images, both cluster sizes, 2 GB to 2 TB. Because the addresses are fixed, a copy whose signature is destroyed is reported as damaged-at-a-known-address rather than absent (K032). WITNESS (offsets are ABSOLUTE in the image file, = partition_start + LCN x cluster): win11refsmini.raw, partition_start 0x1000000, cluster 4096, total_sectors 4063232 x 512 -> backups at LCN 0x7bffd = file offset 0x7cffd000 and LCN 0x7bffe = file offset 0x7cffe000; 4 bytes at each read 'SUPB'. Verified by direct read 2026-09-19.",N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
FS_CHKP_001,File System,Checkpoint,Page header with signature 'CHKP',PRADE-TR,p.54,3.4,3.4;3.14,High,No,CONFIRMED,CHKP string found in binary; checkpoint read during mount sequence,CONFIRMED,CHKP signature at offset 0x00 of both checkpoint pages in all images,E1,E1,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_CHKP_002,File System,Checkpoint,0x54-0x56: major ReFS version,PRADE-TR,p.54,3.4,3.4;3.14,High,No,CONFIRMED,Raw disk analysis: always 3 across all images (filesystem_category.md Section 3.1),CONFIRMED,Major version matches VBR: 3 in all images,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_CHKP_003,File System,Checkpoint,0x56-0x58: minor ReFS version,PRADE-TR,p.54,3.4,3.4;3.14,High,No,CONFIRMED,"Raw disk analysis: 4 for Win10, 14 for Win11; confirmed across all images",CONFIRMED,Minor version matches VBR: 4(Win10) or 14(Win11),N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_CHKP_004,File System,Checkpoint,0x58-0x5C: self-descriptor offset,PRADE-TR,p.54,3.4,3.4,High,No,CONFIRMED,verify_static.py: decompiled code / function catalog evidence,CONFIRMED,Self-descriptor offset used for root reference size calculation; confirmed at 0x5C,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
FS_CHKP_005,File System,Checkpoint,0x60-0x68: checkpoint virtual clock,PRADE-TR,p.54,3.4,3.4,High,No,CONFIRMED,GetCurrentCheckpointVirtualClock function exists in all builds; clock incremented at each checkpoint. Insider-only: CmsRollbackProtection stores this in UEFI NVRAM for anti-rollback,CONFIRMED,"Virtual clock present at BOTH CHKP+0x10 and CHKP+0x60; they agree on every corpus volume measured. The DRIVER'S SELECTION comparator ChooseCheckpointRecord<0> (win11 10.0.26100.8115 @1401051b0) reads +0x60 ONLY, and returns a distinct value on a tie rather than picking a side. Prade's +0x60 is correct for the selection field; the earlier note 'not 0x60 as in Prade' is withdrawn (E101). Clock increases monotonically; higher value selects among checksum-valid copies.",E2 (insider),E2,insider,yes,CONFIRMED,prior_work,3.4,3.4,
FS_CHKP_006,File System,Checkpoint,0x68-0x70: allocator virtual clock,PRADE-TR,p.54,3.4,3.4,High,No,CONFIRMED,Raw disk analysis: allocator clock ranges 23-7200+ across all images; separate from but correlated with virtual clock,CONFIRMED,Allocator clock always slightly lower than checkpoint virtual clock (typically vclock-3 to vclock-5),N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
FS_CHKP_007,File System,Checkpoint,0x70-0x78: oldest log record reference (compound u64: byte offset + segment number),PRADE-TR,p.54,3.4,3.4,High,No,CONFIRMED,CmsDurableLog::GetRecoveryDurableLsn returns oldest LSN needed; used by CmsRestarter for analysis pass start,INFERRED,"Compound u64: low 32 bits = log area byte offset, high 32 bits = log segment number. Both CHKPs always identical. Values range from 0x39 (minimal) to 0x138C8 (heavy usage). See ra_step4_12_deep_structure_report.md | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): LOW. Offset/size disk-confirmed; the 'oldest log record reference' compound-field semantic is E2/structural, not byte-checkable here.",E2,E2,all,no,INFERRED,prior_work,3.4,3.4,
FS_CHKP_008,File System,Checkpoint,0x90-0x94: pointer count (13 global tables),PRADE-TR,p.54,3.4,3.4;3.14,High,No,CONFIRMED,13 global table references confirmed through function analysis of checkpoint initialization code,CONFIRMED,All images report exactly 13 global root tables from checkpoint; field at offset 0x90,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_CHKP_009,File System,Checkpoint,Global table 0x02: Object ID Table,PRADE-TR;PRADE-ART,p.55;S2,3.4,3.4;3.14,High,No,CONFIRMED,"CmsObjectTable class (31 funcs Win10 / 29 Win11); InitializeTable, GetObjectRecordOfIdentifier",CONFIRMED,Root #0 has table ID 0x02 in all images; successfully parsed by refs_object_table.py,E2,E2,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_CHKP_010,File System,Checkpoint,Global table 0x21: Medium Allocator Table,PRADE-TR;PRADE-ART,p.55;S2,3.4,3.4,High,No,CONFIRMED,Allocator tables managed by CmsAllocatorBase (Win10) / CmsAllocator (Win11),CONFIRMED,Root #1 has table ID 0x21; uses virtual addressing (container-translated),E2,E2,win10,yes,CONFIRMED,prior_work,3.4,3.4,
FS_CHKP_011,File System,Checkpoint,Global table 0x20: Container Allocator Table,PRADE-TR;PRADE-ART,p.55;S2,3.4,3.4,High,No,CONFIRMED,Same allocator infrastructure,CONFIRMED,Root #2 has table ID 0x20; uses virtual addressing (INVALIDATES Prade claim of real addressing),N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
FS_CHKP_012,File System,Checkpoint,Global table 0x01: Schema Table,PRADE-TR;PRADE-ART,p.55;S2,3.4,3.4;3.14,High,No,CONFIRMED,CmsSchemaTable class (7 funcs Win10),CONFIRMED,Root #3 has table ID 0x01; parsed by refs_schema.py on all images,E2 (win10),E2,win10,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_CHKP_013,File System,Checkpoint,Global table 0x03: Parent Child Table,PRADE-TR;PRADE-ART,p.55;S2,3.4,3.4,High,No,CONFIRMED,CmsObjectTable::DoomParentChild and PreCowParentChildLink confirm parent-child tracking,CONFIRMED,Root #4 has table ID 0x03; parsed by refs_parentchild.py,E2,E2,,yes,CONFIRMED,prior_work,3.4,3.4,
FS_CHKP_014,File System,Checkpoint,Global table 0x04: Object ID Table (duplicate),PRADE-TR;PRADE-ART,p.55;S2,3.4,3.4,High,No,CONFIRMED,Duplicate confirmed by dual-table init pattern,CONFIRMED,Root #5 has table ID 0x04; same structure as root #0,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
FS_CHKP_015,File System,Checkpoint,Global table 0x05: Block Reference Count Table,PRADE-TR;PRADE-ART,p.55;S2,3.4,3.4,High,No,CONFIRMED,CmsBlockRefcount class (23 funcs Win10 / 27 Win11),CONFIRMED,Root #6 has table ID 0x05; valid MSB+ pages,E2,E2,all,yes,CONFIRMED,prior_work,3.4,3.4,
FS_CHKP_016,File System,Checkpoint,Global table 0x0B: Container Table,PRADE-TR;PRADE-ART,p.55;S2,3.4,3.4;3.14,High,No,CONFIRMED,CmsVolumeContainer class manages container table,CONFIRMED,Root #7 has table ID 0x0B; uses REAL LCNs (bootstrap exception); VLCN=PLCN in all images,E2,E2,all,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_CHKP_017,File System,Checkpoint,Global table 0x0C: Container Table (duplicate),PRADE-TR;PRADE-ART,p.55;S2,3.4,3.4,High,No,CONFIRMED,Dual container table pattern confirmed,CONFIRMED,Root #8 has table ID 0x0C; uses REAL LCNs; VLCN=PLCN,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
FS_CHKP_018,File System,Checkpoint,Global table 0x06: Schema Table (duplicate),PRADE-TR;PRADE-ART,p.55;S2,3.4,3.4,High,No,CONFIRMED,Dual schema table pattern confirmed,CONFIRMED,Root #9 has table ID 0x06; uses virtual addressing,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
FS_CHKP_019,File System,Checkpoint,Global table 0x0E: Container Index Table,PRADE-TR;PRADE-ART,p.55;S2,3.4,3.4;3.14,High,No,NOT_TESTED,,CONFIRMED,Root #10 has table ID 0x0E; valid MSB+ pages in all images,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_CHKP_020,File System,Checkpoint,Global table 0x0F: Integrity State Table,PRADE-TR;PRADE-ART,p.55;S2,3.4,3.4;3.14,High,No,CONFIRMED,"CmsIntegrityState class (win10=17, win11=12, insider=13; contraction, not growth)",CONFIRMED,Root #11 has table ID 0x0F; present in all images regardless of integrity setting,E2,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_CHKP_021,File System,Checkpoint,Global table 0x22: Small Allocator Table,PRADE-TR;PRADE-ART,p.55;S2,3.4,3.4;3.14,High,No,CONFIRMED,Part of allocator table hierarchy,CONFIRMED,Root #12 has table ID 0x22; uses REAL LCNs (bootstrap fallback); VLCN=PLCN in all images,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_SCHM_001,File System,Schema Table,"Defines table schemas, key datatypes, flags, sizes",PRADE-TR,pp.56-59,3.4,3.4;3.14,High,Yes,CONFIRMED,CmsSchemaTable class present; CmsKeyRules class (5 funcs) handles key comparison rules per schema,CONFIRMED,Schema table parsed on all images; 27 entries (3.4) / 29 entries (3.14),E2,E2,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_OTBL_001,File System,Object Table,Key: table identifier,PRADE-TR,pp.59-60,3.4,3.4;3.14,High,No,CONFIRMED,CmsObjectTable::GetObjectRecordOfIdentifier takes table ID key,CONFIRMED,Object table key is 16 bytes: 8-byte padding + 8-byte OID; confirmed on all images,E2,E2,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_OTBL_002,File System,Object Table,Value: page ref + durable LSN + variable buffer. Row header 8xu32 at start; u32[6]+u32[7] = the durable LSN named here (u32[6]=offset in segment; u32[7]=segment) — NOT a generation counter and NOT the checkpoint virtual clock (E104),PRADE-TR,pp.59-60,3.4,3.4,High,No,CONFIRMED,verify_static.py: decompiled code / function catalog evidence,ENRICHED,"Deep decode (FS_OTBL_RA_002): 8xu32 header (format=2, reserved, key_off=0x18, val_off=0x30, payload_offset, payload_length, lsn_offset@u32[6], lsn_segment@u32[7] — E104) + LCN tuple (4xQ) + checksum. B+-tree value_length = 240/248 legacy / 80/88 compact (104/112 under SHA-256), compact from v3.10. Prade 200/208 = value+0x10 offset + value+0x14 length = the payload extent.",N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,dossier FS_OTBL_002.md: Re-verification verdict CONFIRMED-ALLDISK — OT value header decoded on 34522/34522 rows across 113/113 ReFS images: value+0x00==0x2 (100%); u32[2] (value+0x08)==0x1
FS_OTBL_003,File System,Object Table,Duplicate copy exists for resilience,PRADE-TR;PRADE-ART,p.60;S3,3.4,3.4;3.14,High,No,CONFIRMED,Dual Object ID Table (IDs 0x02 and 0x04) confirmed,CONFIRMED,Roots #0 (ID 0x02) and #5 (ID 0x04) are duplicate Object ID Tables in all images,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_OTBL_004,File System,Object Table,Root directory ID = 0x600,PRADE-ART,S3,3.4,3.4;3.14,High,No,CONFIRMED,Raw disk analysis: OID 0x600 confirmed as root directory on all 39 images,CONFIRMED,OID 0x600 = Root Directory in all 39 images; used as start point by refs_dirfiles.py,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_OTBL_005,File System,Object Table,File System Metadata ID = 0x520 (like NTFS $Extend),PRADE-ART,S3,3.4,3.4;3.14,High,No,CONFIRMED,Raw disk analysis: OID 0x520 confirmed present on all 39 images,CONFIRMED,OID 0x520 = File System Metadata present in all images,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_UPCS_001,File System,Upcase Table,UTF-16 uppercase array for case-insensitive names,PRADE-TR,pp.61-62,3.4,3.4;3.14,High,No,CONFIRMED,"Raw disk analysis: 65536 entries (131072 bytes), 973 non-identity mappings, identical across all 39 images",CONFIRMED,Upcase table (OID 0x7) parsed by refs_upcase.py; 65536 UTF-16 entries in all images,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_VINF_001,File System,Volume Info Table,"Volume label row (key 0x510, UTF-16)",PRADE-TR,p.63,3.4,3.4;3.14,High,No,CONFIRMED,$VOLUME_NAME and $VOLUME_INFORMATION string literals confirmed in binary,CONFIRMED,Volume label extracted as UTF-16LE from key 0x510 row; refs_volume_info.py works on all images,E1,E1,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FS_VINF_002,File System,Volume Info Table,"General info: creation/mount times, version",PRADE-TR,p.63,3.4,3.4,High,No,CONFIRMED,verify_static.py: decompiled code / function catalog evidence,CONFIRMED,"Volume info rows contain timestamps (creation, last mount) parsed by refs_volume_info.py",N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
FS_VINF_003,File System,Volume Info Table,Backup block row (key 0x540),PRADE-TR,p.63,3.4,3.4;3.14,High,No,CONTRADICTED,verify_static.py: decompiled code / function catalog evidence | SA reconciled 2026-06-20: verify_static evidence is co-occurrence/cited only (NOT function-scoped) after the >=3-regex gate fix; overall verdict rests on the raw_analysis (RD) column.,CONTRADICTED,"OID 0x540 present in Object Table of all images | RE-VERIFIED 2026-06-18 (all-disk): claimed 'Backup block row (key 0x540)'; disk shows key 0x540 in OID 0x500 = schema count (35) + flags, exactly as structure_reference §F.4b labels it. There is no 'backup block' here. The audit description mislabels this row.",N/A,NONE,,yes,CONTRADICTED,prior_work,3.4,3.4;3.14,
FS_PCHL_001,File System,Parent-Child Table,Key+value: parent table ID + child table ID,PRADE-TR;LEE-JRN,p.61;p.3,3.4,3.4;3.14,High,No,CONFIRMED,PreCowParentChildLink and DoomParentChild functions confirm parent-child tracking mechanism,CONFIRMED,Parent-child relationships parsed on all images; enables directory tree reconstruction via refs_parentchild.py,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
CT_ALLC_001,Content,Small Allocator,Manages own tree + Med Alloc + BRC + Integrity State,PRADE-TR;PRADE-ART,pp.37-38;S2,3.4,3.4;3.14,High,No,CONFIRMED,Three-tier allocator confirmed: Small+Medium+Container allocators; managed by CmsAllocatorBase(Win10) / unified CmsAllocator(Win11),INFERRED,"Small Allocator (root #12) uses real LCNs as bootstrap fallback; confirmed in all 39 images | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): Behavioral claim 'Manages own tree + Med Alloc + BRC + Integrity State' - the structural pieces are disk-present (3-tier allocator rows, integrity-state table) and E2-symbol-backed, but the 'manages' relationship is not a single b",E2,E2,win10,no,INFERRED,prior_work,3.4,3.4;3.14,
CT_ALLC_002,Content,Medium Allocator,Main allocator for trees and file contents,PRADE-TR;PRADE-ART,pp.37-38;S2,3.4,3.4;3.14,High,No,CONFIRMED,AllocateLcns function (7511 bytes Win10) handles extent allocation,CONFIRMED,Medium Allocator (root #1) uses virtual addressing; valid MSB+ pages in all images,E2 (win10),E2,win10,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
CT_ALLC_003,Content,Container Allocator,Allocator for itself and Container Table,PRADE-TR;PRADE-ART,pp.37-38;S2,3.4,3.4,High,No,CONFIRMED,CmsContainerRangeMap (26/22 funcs) manages container-level allocation,ENRICHED,Container Allocator (root #2) uses VIRTUAL addressing (contradicts Prade claim of real addressing),E2,E2,all,no,UNSTATED,prior_work,3.4,3.4,dossier CT_ALLC_003.md: Re-verification verdict STATIC-CITED — **Original audit verdict:** STATIC-CITED  (disk held 0/1 at audit time)  ·  **Registry status:** ENRICHED  ·  **Evidence
CT_CTBL_001,Content,Container Table,Key: container identifier,PRADE-TR;LEE-JRN,p.61;p.3,3.4,3.4,High,No,CONFIRMED,"Raw disk analysis: 16-byte key [u64 container_id, u64 0x100000000] confirmed on all 39 images",CONFIRMED,Container ID is the key in B+-tree; sequential from 0 to container_count-1,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
CT_CTBL_002,Content,Container Table,Translation: Container_ID = LCN >> CPC_BitCount,LEE-JRN,p.3,3.4,3.4;3.14,High,No,CONFIRMED,Raw disk analysis: formula verified on all 39 images; shift=15 for 4K / 11 for 64K (corrected per E18 — prior 14/10 omitted the +1),CONFIRMED,Formula verified: Container_ID = VLCN >> shift; shift=15 for 4K / 11 for 64K (corrected per E18 — prior 14/10 omitted the +1). Tested on all 39 images,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
CT_CTBL_003,Content,Container Table,Translation: CN = LCN & (CPC - 1),LEE-JRN,p.3,3.4,3.4,High,No,CONFIRMED,Raw disk analysis: mask formula verified on all images,CONFIRMED,Offset within container: VLCN & (CPC-1). CPC=16384(4K) or 1024(64K),N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
CT_CTBL_004,Content,Container Table,Translation: PCN = CSC + CN,LEE-JRN,p.3,3.4,3.4;3.14,High,No,CONFIRMED,Raw disk analysis: CSC from container_map[id] + offset gives correct PLCN on all images,CONFIRMED,PLCN = container_map[container_id] + offset. Verified by successful page reads on all images,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
CT_CTBL_005,Content,Container Table,0x20-0x28: free clusters in container (Prade),PRADE-TR,p.61,3.4,not_verified,Medium,Yes,CONFIRMED,Raw disk analysis: free cluster count at offset 0x20 confirmed (values correlate with usage),INFERRED,"Row field interpretation not yet implemented in detail | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was NOT_TESTED): Prade '0x20-0x28 free clusters' - the OFFSET holds a value consistent with a free-cluster count (<=CPC, varies with usage) but the SEMANTIC 'free clusters' is not E2-confirmed (no driver symbol tied). Note structure_reference dist",N/A,NONE,,no,INFERRED,prior_work,3.4,unknown,
CT_CTBL_006,Content,Container Table,"0x90-0x98: physical start LCN (4K clusters, Prade)",PRADE-TR,p.61,3.4,3.4;3.14,Medium,Yes,ENRICHED,Raw disk analysis: CONFIRMED for 160-byte rows only; for 224-byte rows (SHA256/64K) phys_start is at 0xD0. Universal: value[len-16:len-8] (CT_CTBL_RA_001),CONTRADICTED,NORMALIZED 2026-06-19 (was INVALIDATED): Position-independent: phys_start at row[-16] (last 16 bytes). For 160-byte rows: offset 0x90 is correct; fails on 224-byte rows. Universal formula: row[len(row)-16]. Works for 160-byte (0x90) and 224-byte (0xD0). Merged from CT_CTBL_RA_002,N/A,NONE,,yes,CONTRADICTED,prior_work,3.4,3.4;3.14,
CT_CTBL_007,Content,Container Table,"0xD0-0xD8: physical start LCN (64K clusters, Prade)",PRADE-TR,p.61,3.4,3.4,Medium,Yes,CONFIRMED,"Raw disk analysis: confirmed for 224-byte rows (64K clusters AND SHA256 4K both use 224-byte rows, CT_CTBL_RA_003)",CONFIRMED,For 224-byte rows (64K or SHA256): row[-16]=offset 0xD0 is correct,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
CT_CTBL_008,Content,Container Table,"0x98-0xA0: number of clusters (4K, Prade)",PRADE-TR,p.61,3.4,not_verified,Medium,Yes,ENRICHED,Raw disk analysis: CPC is at universal offset 0x18 (not 0x98); value[len-8:len-4] contains a CPC copy. Prade's 0x98 is the trailing copy in 160-byte rows,INFERRED,"DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was NOT_TESTED): Prade '0x98-0xA0 number of clusters (4K)'. On disk, 0x98 (for 160B rows) holds the CPC trailing copy (=16384), which IS the number of clusters per container. So Prade's offset+semantic are essentially correct: 0x98=cluster count(=",N/A,NONE,,no,INFERRED,prior_work,3.4,unknown,
CT_CTBL_009,Content,Container Table,0x10-0x17: Container ID (Lee),LEE-JRN,p.3,3.4,not_verified,Medium,Yes,CONFIRMED,Needs raw disk verification,CONFIRMED,Key contains container ID but exact offset within row value not yet verified,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,unknown,
CT_CTBL_010,Content,Container Table,"row+0xA0 (ROW-relative, not value-relative) = the container's physical start cluster, on 160-byte Container-Table rows. NOT applicable to 224-byte rows, where row+0xA0 is not the start in either frame (E106).",LEE-JRN,p.3,3.4,not_verified,Medium,Yes,CONTRADICTED,Needs raw disk verification | SA reconciled 2026-06-20: verify_static evidence is co-occurrence/cited only (NOT function-scoped) after the >=3-regex gate fix; overall verdict rests on the raw_analysis (RD) column.,CONTRADICTED,"E106: the earlier CONTRADICTED verdict measured VALUE-relative, where 0xA0 is past the end of a 160-byte value - a fact about the value, not about the row. Measured row-relative: row+0xA0 == the physical container start on 31/31 rows of win10refsmini (v3.4) and 31/31 of win11refsmini (v3.14), both 160-byte values, while value+0xA0 is out of bounds on all 62. On 224-byte values (win11refs2g_sha256checksums 1/31, win11refs5g64k 1/79) row+0xA0 is NOT the start. CT_CTBL_009 from the same source is row-relative and CONFIRMED, so the register was internally inconsistent about the frame. Every register offset needs its origin named.",N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
CT_CTBL_011,Content,Container Table,0xA8-0xAC: CPC clusters per container (Lee),LEE-JRN,p.3,3.4,3.4;3.14,Medium,Yes,ENRICHED,"Raw disk analysis: INVALIDATED — CPC is at universal offset 0x18, NOT at 0xA8. Lee's offset is incorrect",CONTRADICTED,CPC is at offset 0x18 universally (not 0xA8 as Lee claims). Confirmed across all 39 images including 64K clusters and SHA256. Merged from CT_CTBL_RA_001 | RE-VERIFIED 2026-06-18 (all-disk): value+0xA8 (u32) == 0 on 278873/278873 224-byte rows (CPC@0xA8 never matches the real CPC 16384/1024). CPC is at value+0x18 (and trailing copy at 0x98/0xD8). 0xA8 is out of bounds for 160B rows.,N/A,NONE,,yes,CONTRADICTED,prior_work,3.4,3.4;3.14,
CT_DRNT_001,Content,Data Run Table,Starting LCN of data run,PRADE-TR,p.67,3.4,3.4,High,No,CONFIRMED,CmsStream::LookupAllocation / AddAllocation / DeleteAllocation manage extent maps; data runs map VCN→LCN,NOT_TESTED,,E2,E2,all,no,NOT_TESTED,prior_work,3.4,3.4,
CT_DRNT_002,Content,Data Run Table,"Flags: 0x0080 = CRC32-C per cluster, 0x0100 = CRC64. Bit 0x0010 means WRITTEN, as of the row version that carries it (E113, N63): a run whose flags word is known and has 0x10 clear was allocated but not written when that row version was committed, and its clusters are not the file's content. Rows carrying 0x40 WITHOUT 0x10 number 267 of 571 on win10refs8g (v3.4), 214/512 on win10refs5g64k, 532/1,593 on win10refs2tspecials, 1,254/2,724 on win11refstestmftecmd and 976/162,098 on winsider -- their clusters can hold bytes, but those bytes are another file's or a later write's (winsider: 693 such runs serve foreign bytes, among them readable text). The bit belongs to the ROW VERSION, not the cluster: for the same VLCN the live row can carry 0x00D0 and a deleted prior-version remnant 0x0040. A flags word of 0 is UNKNOWN (the marker-scan decoder recovers no flags), not unwritten. Bit 0x0080 holds: on lab314_main, win10refs8gsetintegristystreams1 and win11refs2tintegrity, 976 of 976 rows carrying it declare row_size == 24 + 4*run, and 3,428 of 3,428 trailing u32 values equal the CRC-32C (poly 0x82F63B78) of the cluster they cover, with 0 mismatches. Measured over 174,652 extent rows of both storage forms on 12 volumes.",PRADE-TR,p.67,3.4,not_verified,High,No,NOT_TESTED,Flag constants need raw disk verification,CONTRADICTED,"PT: Extent flags at value[0x00] verified. OID 0x707 on win11refslasttests: flags=0x00A8 | RE-VERIFIED 2026-06-18 (all-disk): claimed 0x0010=data / 0x0080=CRC32 / 0x0100=CRC64; disk shows bit 0x10 is NOT 'data' (0x180040 data run lacks it), bit 0x80 marks the integrity-stride entry (0x1c00d0), and bit 0x100 (CRC64) appears in 0 of all clean extent flags corpus-wid | E113 (2026-09-23): the 2026-06-18 re-verification read 'the 0x180040 data run lacks bit 0x10' as proof the bit is not a data marker; it counted clusters that HOLD bytes, not clusters that hold THIS FILE's bytes. N63 supplies the ground truth (LAB-E 7/7 byte-exact only under the rule; the e5 inverse control; winsider's 693 foreign-byte runs). disk_status left CONTRADICTED pending re-measurement of the LAB-E witness in the 1.13.1 cycle -- a status is not changed on an argument.",N/A,NONE,,yes,CONTRADICTED,prior_work,3.4,unknown,
CT_DRNT_003,Content,Data Run Table,Total length of data run,PRADE-TR,p.67,3.4,not_verified,High,No,NOT_TESTED,,CONFIRMED,PT: Extent length field at value[0x08] verified on win11refslasttests,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,unknown,
CT_DRNT_004,Content,Data Run Table,Optional per-cluster checksums,PRADE-TR,p.67,3.4,3.4,High,No,CONFIRMED,CmsIntegrityState manages per-page checksums; checksum area confirmed in data run structure,NOT_TESTED,,E2,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,no,NOT_TESTED,prior_work,3.4,3.4,
CT_CNTX_001,Content,Container Index Table,Named but no field layout provided,PRADE-TR,p.41,3.4,3.4;3.14,Low,Yes,NOT_TESTED,,CONFIRMED,"Container Index Table (root #10, ID 0x0E) exists with valid MSB+ pages in all images",N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
CT_INTS_001,Content,Integrity State Table,"Row format decoded: Key=16B [u64 start_lcn, u64 block_count], Value=24B [u64 start_lcn(dup), u64 block_count(dup), u32 state_field, u32 config_field]. Rows cover contiguous LCN ranges spanning entire volume. Most images: 1 row with default [0x0002ffff, 0x00000100]. Large Win10: 3 rows — 1 container has modified state [0x00013f6c, 0x00000118]. Linked to Container Table extended area (per-container checksum buffer). CmsIntegrityState class win10=17, win11=12, insider=13 (contraction, not growth)",PRADE-TR,p.41,3.4,3.4;3.14,High,No,ENRICHED,"CmsIntegrityState class win10=17, win11=12, insider=13 (contraction, not growth). UpdateIntegrityState called during allocator operations. GetIntegrityStateTable returns IST BPlusTable. Row format confirmed via 85-distinct-ReFS-image scan (re-scan 2026-08-20; the earlier '89' counted duplicate .raw copies across step dirs)",CONFIRMED,"IST (root #11) present on ALL 85 distinct ReFS images (re-scan 2026-08-20, integrity_state_fullscan.py). Row format invariant: Key=16B, Value=24B. 83/85: single row covering entire volume. 2/85: 3 rows (large Win10 v3.4 — win10refs110g, win10refs2tspecials) with 1 container having modified integrity state [0x00013f6c/0x00000118]",E2 (win10),E2,win10,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
CT_BKRC_001,Content,Block Ref Count Table,Inferred support for cloning/dedup; fields unknown,PRADE-TR;WININT,p.41,3.4,3.4;3.14,Medium,Yes,ENRICHED,CmsBlockRefcount class: 23 funcs (Win10) / 27 funcs (Win11). Used for dedup/clone reference counting,INFERRED,"Block Ref Count Table (root #6, ID 0x05) present in all images; no visible structural difference on dedup-enabled volumes | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): 'Inferred support for cloning/dedup; fields unknown' - the cloning/dedup support is E2-corroborated and the populated-only-on-sharing-volumes behavior is disk-observed (empty on plain v3.4/v3.14). Fields are actually now KNOWN (se",E2,E2,all,no,INFERRED,prior_work,3.4,3.4;3.14,
CT_MISC_001,Content,B+ Tree Remnants,B+ tree balancing leaves recoverable remnants,NORDVIK,p.128,3.2,3.4;3.14,Medium,Yes,CONFIRMED,CoW B+-tree model means old pages persist until space reclaimed. CmsBPlusTable never overwrites in-place,CONFIRMED,Log data area contains MSB+ pages (logged copies of old tree state); confirms CoW remnant persistence,E2,E2,all,yes,CONFIRMED,prior_work,3.2,3.4;3.14,
CT_MISC_002,Content,Trash Stream Table,Large deleted files retained; threshold by data-run count,PRADE-TR,pp.29-30,3.4,3.4,Medium,Yes,CONFIRMED,"CmsTrashTable class - distinct mangled symbols per PDB: 12 (win10 17134), 20 (26100.8115), 20 (.8521), 19 (.8972), 19 (.9444), 19 (insider 29574). The single symbol lost after 26100.8521 is ?InitializeLibrary@CmsTrashTable@@SAXXZ, a genuine removal rather than inlining. Manages deferred deletion of large files. Quote the build with the count - '20 funcs (Win11)' is true of two builds of the four.",NOT_TESTED,,E2,E2,all,no,NOT_TESTED,prior_work,3.4,3.4,
MD_DDIR_001,Metadata,Directory Descriptor,Creation time,PRADE-TR,p.66,3.4,3.4;3.14,High,No,CONFIRMED,RefsComputeStandardInformationFromFcb maps CreationTime at offset 0x00 in $SI,CONFIRMED,Directory timestamps extracted by refs_dirfiles.py; creation time confirmed in all images,E2,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
MD_DDIR_002,Metadata,Directory Descriptor,Modification time,PRADE-TR,p.66,3.4,3.4,High,No,CONFIRMED,Mapped at offset 0x08 in $SI,CONFIRMED,Modification time parsed and displayed for all directories,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
MD_DDIR_003,Metadata,Directory Descriptor,Metadata modification time,PRADE-TR,p.66,3.4,3.4,High,No,CONFIRMED,Mapped at offset 0x10 in $SI,NOT_TESTED,,N/A,NONE,,no,NOT_TESTED,prior_work,3.4,3.4,
MD_DDIR_004,Metadata,Directory Descriptor,Access time (may be disabled),PRADE-TR,p.66,3.4,3.4,High,No,CONFIRMED,Mapped at offset 0x18 in $SI,NOT_TESTED,,N/A,NONE,,no,NOT_TESTED,prior_work,3.4,3.4,
MD_DDIR_005,Metadata,Directory Descriptor,Flags,PRADE-TR,p.66,3.4,3.4;3.14,High,No,CONFIRMED,FileAttributes at offset 0x20 in $SI,CONFIRMED,Directory flag is 0x10000000 (bit 28) not 0x10 as in Win32. Discovered via Bug #4 during tool development. Confirmed across all 39 images. Non-standard encoding specific to ReFS internal representation. Merged from MD_DDIR_RA_001,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
MD_DDIR_006,Metadata,Directory Descriptor,Security descriptor ID,PRADE-TR,p.66,3.4,3.4,High,No,CONFIRMED,SecurityId at offset 0x28 in $SI,NOT_TESTED,,N/A,NONE,,no,NOT_TESTED,prior_work,3.4,3.4,
MD_FTBL_001,Metadata,File Table,Creation time,PRADE-TR,p.66,3.4,3.4;3.14,High,No,CONFIRMED,Same $SI pipeline used for files and directories,CONFIRMED,"File timestamps extracted by refs_dirfiles.py across all images | DUPLICATE of MD_DDIR_001: prior work tabulated the same $SI field twice, once under 'File Table' and once under 'Directory Descriptor'. The project measured ONE structure -- a file's $SI and a directory's $SI share the layout (attributes/STANDARD_INFORMATION.md) -- so the two rows describe the same field. Both are kept: each records a distinct prior-work table.",N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
MD_FTBL_002,Metadata,File Table,Modification time,PRADE-TR,p.66,3.4,3.4,High,No,CONFIRMED,,CONFIRMED,"Modification time displayed for all files | DUPLICATE of MD_DDIR_002: prior work tabulated the same $SI field twice, once under 'File Table' and once under 'Directory Descriptor'. The project measured ONE structure -- a file's $SI and a directory's $SI share the layout (attributes/STANDARD_INFORMATION.md) -- so the two rows describe the same field. Both are kept: each records a distinct prior-work table.",N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
MD_FTBL_003,Metadata,File Table,Metadata modification time,PRADE-TR,p.66,3.4,3.4,High,No,CONFIRMED,,NOT_TESTED," | DUPLICATE of MD_DDIR_003: prior work tabulated the same $SI field twice, once under 'File Table' and once under 'Directory Descriptor'. The project measured ONE structure -- a file's $SI and a directory's $SI share the layout (attributes/STANDARD_INFORMATION.md) -- so the two rows describe the same field. Both are kept: each records a distinct prior-work table.",N/A,NONE,,no,NOT_TESTED,prior_work,3.4,3.4,
MD_FTBL_004,Metadata,File Table,Access time,PRADE-TR,p.66,3.4,3.4,High,No,CONFIRMED,,NOT_TESTED," | DUPLICATE of MD_DDIR_004: prior work tabulated the same $SI field twice, once under 'File Table' and once under 'Directory Descriptor'. The project measured ONE structure -- a file's $SI and a directory's $SI share the layout (attributes/STANDARD_INFORMATION.md) -- so the two rows describe the same field. Both are kept: each records a distinct prior-work table.",N/A,NONE,,no,NOT_TESTED,prior_work,3.4,3.4,
MD_FTBL_005,Metadata,File Table,Flags,PRADE-TR,p.66,3.4,3.4,High,No,CONFIRMED,,CONFIRMED,"ARCHIVE, HIDDEN, SYSTEM, REPARSE_POINT flags confirmed in directory entries",N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
MD_FTBL_006,Metadata,File Table,Security descriptor ID,PRADE-TR,p.66,3.4,3.4,High,No,CONFIRMED,,NOT_TESTED," | DUPLICATE of MD_DDIR_006: prior work tabulated the same $SI field twice, once under 'File Table' and once under 'Directory Descriptor'. The project measured ONE structure -- a file's $SI and a directory's $SI share the layout (attributes/STANDARD_INFORMATION.md) -- so the two rows describe the same field. Both are kept: each records a distinct prior-work table.",N/A,NONE,,no,NOT_TESTED,prior_work,3.4,3.4,
MD_FTBL_007,Metadata,File Table,Size / Allocated size,PRADE-TR,p.66,3.4,3.4,High,No,CONFIRMED,RefsSetEndOfFileInfo updates file size; RefsWriteFileSizes updates valid data length,CONFIRMED,File sizes correctly parsed from directory entries; matches expected values from Generate-FSActivity,E2,E2,all,yes,CONFIRMED,prior_work,3.4,3.4,
MD_ATTR_001,Metadata,Attributes,"$STANDARD_INFORMATION: present, role moved to fixed metadata",PRADE-TR,pp.33+67,3.4,3.4,High,Yes,CONFIRMED,"RefsMapStandardInfo validates size >= 0x74 (116 bytes Win10). Functions: RefsMapStandardInfo, RefsGetStandardInfo, RefsSetStandardInfo, RefsComputeStandardInformationFromFcb",INFERRED,"Individual attribute extraction not yet implemented | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was NOT_TESTED): Offset/presence disk-confirmed; the prose label is static-cited (E2 win10). No contradiction.",E2 (win10),E2,win10,no,INFERRED,prior_work,3.4,3.4,
MD_ATTR_002,Metadata,Attributes,$FILENAME: present in driver,PRADE-TR,p.33,3.4,3.4,High,No,CONFIRMED,$FILE_NAME string literal in both versions; RefsMapFileName function,CONFIRMED,Filenames extracted from directory B+-trees by refs_dirfiles.py; UTF-16LE decoding confirmed,E1 (all),E1,all,yes,CONFIRMED,prior_work,3.4,3.4,
MD_ATTR_003,Metadata,Attributes,"$DIR_LINK: new in ReFS, stores dir name+parent ID+timestamps",PRADE-TR,pp.43+68,3.4,3.4,High,No,CONFIRMED,$DIR_LINK string literal in both versions; Win11 adds RefsAttributeManager::CreateLinkAttribute (4030B) and DeleteLinkAttribute (2567B),CONFIRMED,Directory names extracted via B+-tree walking; parent-child relationships confirmed,E1 (all),E1,all,yes,CONFIRMED,prior_work,3.4,3.4,
MD_ATTR_004,Metadata,Attributes,$OBJECT_ID: present but possibly partial support,PRADE-TR,p.33,3.4,3.4,Medium,Yes,CONFIRMED,$OBJECT_ID string literal in BOTH Win10 and Win11. RefsOpenFcbById handles object ID lookups. CONTRADICTS Microsoft docs claiming no Object ID support,NOT_TESTED,,E1,E1,all,no,NOT_TESTED,prior_work,3.4,3.4,
MD_ATTR_005,Metadata,Attributes,"$DATA: the file's content stream. Whether its bytes are INLINE in the record or in on-disk EXTENTS is a property of the VOLUME FORMAT, not of the attribute: on format <=3.10 main $DATA is never inline (Prade et al.'s 'always non-resident' is correct, scoped to those formats); from format 3.11 it is inline while the stream is under 0x800 (2048 B). The 0x20000 (128 KiB) figure is the NAMED-STREAM cap, not a main-data threshold (see MD_ADS_RA_003), and named streams are NOT 'always resident' - 729 of 8,238 are extent-backed. Residency must be read from the $DATA descriptor's own form, never from the name row's length or its key_flags (E77/E87).",PRADE-TR;PRADE-ART,pp.67;S4,3.4;3.7;3.9;3.10;3.14,2026-09,High,No,ENRICHED,"Type code 0x80 confirmed in RefsCheckValidAttributeAccess. The residency gate is RefsAddAllocationForResidentWrite (win11 26100 @1400ddd2c): format <0x30b (3.11) or size <0x800 stays inline, else RefsConvertToNonResident. RefsCheckValidResidentDataAttribute - the DATA-specific validity check - exists only in the v3.14-era drivers; win10 17134 has only the generic RefsCheckValidResidentAttribute and no RefsConvertToNonResident at all. Merged from MD_RESD_SA_001.",CONFIRMED,"RD 2026-09-04, corpus manifest r2 (79 distinct volumes / 507,433 file name rows). Format <=3.10: 5,419 rows over 14 volumes, INLINE=0 and EMPTY=0 - every main $DATA extent-backed, the smallest a 5-byte file holding a whole 4 KiB cluster. Format >=3.11: largest inline 2,047 B, 0 of 399,225 inline rows reach 2,048. PREVIOUS RD CELL WITHDRAWN: 'Win10: 100% resident for small test files. Win11: ~92% resident. Threshold confirmed empirically.' was produced by the value-length>84 rule, which measures RECORD PLACEMENT, not residency - it is the circular reading E87 corrects, and it is contradicted by the descriptor-level measurement above. RD 2026-09-07 (lab314 volumes, PLAN v5 Part C): witnessed on lab314_main / _64k / _4kn (Win11 24H2, ReFS 3.14, 4 KiB / 64 KiB / 4Kn), against ground truth written on the volumes by the operator (inventory.csv 4,657+626+626 files 100% SHA-256; streams.csv per-ADS; hashes.csv; witness/hashes_t12r.csv; fsutil queryfileid). Content proof 5,908/5,909 byte-exact. T4: the 2 KiB inline ceiling on format 3.11+ is EXACT and FIXED, not cluster-relative -- 1,900 B inline / 2,100 B extents for BOTH the main stream and a named stream, identically on 4 KiB, 64 KiB and 4Kn. On 64 KiB clusters a 2,100 B stream occupies a whole 64 KiB cluster. The 128 KiB ADS cap does NOT apply on 3.14: a 131,073-byte ADS exists and reads back byte-exact; the cap remains a <=3.10 rule (E2 + vendor doc, still needs an older VM: T1-T3).",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,unknown,
MD_ATTR_006,Metadata,Attributes,$INDEX_ROOT: present but appears unused,PRADE-TR,p.68,3.4,3.4;3.14,Medium,No,CONFIRMED,$INDEX_ROOT string literal present; type code 0x90,CONFIRMED,Schema type 0x1b0 = Index Root present in Win11 schema table (absent in Win10),E1,E1,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
MD_ATTR_007,Metadata,Attributes,"$NAMED_DATA: ADS, inline, limited size",PRADE-TR,p.68,3.4,3.4,High,No,CONFIRMED,$NAMED_DATA string literal in both versions,INFERRED,"DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was NOT_TESTED): ADS-as-0xB0 disk mechanism confirmed; the attribute-name string and size-limit are static (E1).",E1 (all),E1,all,no,INFERRED,prior_work,3.4,3.4,
MD_ATTR_008,Metadata,Attributes,"$REPARSE_POINT: reparse metadata for symlinks/junctions. Type code 0xC0 (NTFS-equivalent). Stored as separate attribute in per-file B+ tree, not inline in 0x30 directory entry. Schema 0x1c0 (v3.7+), schema 0x170 = Reparse Point tree type.",PRADE-TR,p.68,3.4,3.4;3.14,High,No,CONFIRMED,"$REPARSE_POINT string literal + type code 0xC0. RefsGetReparsePointValue: LookupAttribute(0xc0). RefsCreateReparsePointInternal: CreateAttributeWithValue(0xc0). Reparse tag/flag in 0x30 entry, data in separate 0xC0 attribute",CONFIRMED,REPARSE_POINT flag (0x400) on symlink files. Schema 0x170 = Reparse Point. No 0xC0 entries visible in directory B+ trees (data in per-file attribute set),E1,E1,all,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
MD_ATTR_009,Metadata,Attributes,$USN_INFO: Change Journal org metadata (unofficial name),PRADE-TR,p.68,3.4,not_verified,Low,Yes,NOT_TESTED,Name is analyst-assigned; exact attribute name in binary not confirmed,INFERRED,"RD. OID 0x520 is the File-System-Metadata container. Its name is NOT analyst-assigned and does NOT come from the Parent-Child Table: (a) the Parent-Child Table (CHKP root 4) contains no names at all - on lab314_main it holds 32 rows, every key and value a 32-byte OID pair, 0 rows containing any UTF-16 text, the first being the pair (0x600, 0x520); (b) the name 0x520 actually carries is 'File System Metadata' (20 characters), stored in its own type-0x10 row as a multi-instance (0x80000002) type-0x39 link sub-record with parent OID 0x600 - on lab314_main the sub-record header is at image offset 0x1e081e0.",N/A,NONE,,no,INFERRED,prior_work,3.4,unknown,
MD_ATTR_010,Metadata,Attributes,"$EA_INFORMATION (0xD0) + $EA (0xE0): Extended Attributes. Two-phase lookup: 0xD0 header (sizes/counts), then 0xE0 data body. NTFS-equivalent type codes. Schema 0x1d0 (v3.7+), 0x1e0 (v3.14+). Schema 0x1a0 = EA tree type.",PRADE-TR,p.33,3.4,3.4;3.14,High,No,CONFIRMED,"RefsLookupEasOnFile (Ea.c): LookupAttribute(0xd0) for _EA_INFORMATION header, then LookupAttribute(0xe0) for EA data body. RefsCopyAllEas: LookupAttribute(0xe0). IRP_MJ_QUERY_EA/SET_EA handlers in Win11",CONFIRMED,"Schema 0x1a0 = Extended Attributes in both versions. WSL $LX* EAs found inline in 0x30 value data on disk images. Separate 0xD0/0xE0 attribute entries in per-file attribute set, not visible in directory B+ tree",E2 (win11+),E2,win11+,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
MD_SECT_001,Metadata,Security Table,Centralized security descriptors indexed by security ID,PRADE-TR;LEE-JRN,pp.63-64;p.3,3.4,3.4;3.14,High,No,CONFIRMED,Security ID at offset 0x28 in $SI; SeAccessCheck calls in RefsCommon* functions,CONFIRMED,Security Descriptor Stream (OID 0x530) present in all images' Object Tables,E2,E2,all,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
MD_MISC_001,Metadata,Manipulation,SetMace does not work on ReFS (no $MFT),NORDVIK,p.130,3.2,not_verified,Medium,No,NOT_TESTED,,NOT_TESTED,,N/A,NONE,,no,NOT_TESTED,prior_work,3.2,unknown,
MD_MISC_002,Metadata,Volume Direct IO File,"Unknown metadata file, future work",LEE-JRN,p.3,3.4,not_verified,Low,Yes,NOT_TESTED,,NOT_TESTED,,N/A,NONE,,no,NOT_TESTED,prior_work,3.4,unknown,
FN_DTBL_001,File Name,Directory Table,Directory Descriptor row: type 0x10,PRADE-TR,p.64,3.4,3.4;3.14,High,No,NOT_TESTED,,INFERRED,"Directory entries identified by flag 0x10000000 (bit 28) in all images | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): Semantic label 'Directory Descriptor row: type 0x10' is a Prade naming; the type-0x10 key marker exists on disk but FN_DTBL_005 supersedes the directory-discrimination model (dirs are kf=0x02+attr-bit, not a distinct row type). Of",N/A,NONE,,no,INFERRED,prior_work,3.4,3.4;3.14,
FN_DTBL_002,File Name,Directory Table,"File row: a type-0x30 row carrying a UTF-16LE filename at key+0x04. The full u32 at key+0 takes TWO values, not one: 0x00010030 for an embedded record (key_flags 1) and 0x00020030 for a split one (key_flags 2) - 647,701 and 313,919 rows over 141 images, and the name decodes on 100% of both. A low-16 test (key[0:2] == 0x0030) passes on 961,620/961,620 rows and therefore discriminates nothing; use the full u32, or key_flags, to tell the two forms apart.",PRADE-TR,p.65,3.4,not_verified,High,No,CONFIRMED,verify_static.py: decompiled code / function catalog evidence,ENRICHED,Exact type encoding not yet verified at this level of detail,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,unknown,"dossier FN_DTBL_002.md: Re-verification verdict CONFIRMED-ALLDISK — type-0x30 filename entries: key[0:2]==0x0030 on 525,178/525,178 rows; filename at key+0x04 decodes as UTF-16LE on 525,17"
FN_DTBL_003,File Name,Directory Table,"Type 0x20 is the per-object FileId-resolution index (RefsFindFileId/RefsCreateFileId2), NOT a directory reverse-lookup. Key = 0x80000020 + 0 + FileId(u64) + 0 (24B). Format A (type_flag=0, variable) = filename, for split-record files. Format B (fixed 24B, type_flag=1 on v3.4 / =2 on v3.7+) = {tf, 0, FileId, home-dir back-ref OID}, for subdirectories + cross-dir links. Format B present on v3.4 (as tf=1); tf=1->tf=2 transition at v3.7.",static_analysis;raw_analysis,p.65,both,3.4;3.7;3.14,High,No,CONFIRMED,RefsFindFileId/RefsCreateFileId2 (win11 L487321 / win10 L246686); Format B value = _REFS_FILE_REFERENCE back-pointer. RefsLinkFileToSelf passes own ref; RefsMoveFile cross-dir inserts Format B.,INFERRED,"win10refs2tspecials (v3.4): 113 Format B all tf=1 non-self-referencing. Coverage on OID 0x702: 12 Format A == 12 split-record files; subdirs get Format B. | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): The Format A/B / tf=1->tf=2 transition and the RefsFindFileId semantic are E2+RD (decompilation-grounded); the byte presence of the 0x20 index is disk-confirmed but the detailed semantic discrimination is not a pure byte-layout cl",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,INFERRED,prior_work,3.4;3.14,3.4;3.7;3.14,
FN_DTBL_004,File Name,Directory Table,Directory Link row: type 0x00020030 + dirname,PRADE-TR,p.66,3.4,3.4,High,No,CONFIRMED,$DIR_LINK string confirmed; directory link management functions present,INFERRED,"Directory names extracted from B+-tree walking in refs_dirfiles.py | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): E1 (string $DIR_LINK). On disk these are indistinguishable from other kf=0x02 type-0x30 entries except by the directory attribute bit (FN_DTBL_005). Semantic 'Directory Link' label is literature; byte layout confirmed.",E1,E1,,no,INFERRED,prior_work,3.4,3.4,
FN_ADDR_001,File Name,Metadata Addresses,128-bit: directory_id | file_id; root=0x600,PRADE-ART,S3,3.4,3.4,High,No,ENRICHED,verify_static.py: root=0x600 in OpenRootDirectory; partial static match,CONFIRMED,128-bit keys observed in Object Table (8 bytes padding + 8 bytes OID); root=0x600 confirmed,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
FN_PATH_001,File Name,Path Recovery,OID Table + Parent-Child + dir names for full path,PRADE-TR;LEE-JRN,pp.36-37;p.7,3.4,3.4;3.14,High,No,CONFIRMED,Full path reconstruction chain: CmsObjectTable → parent-child → directory rows → $DIR_LINK,CONFIRMED,refs_dirfiles.py implements full path reconstruction via OID+Parent-Child+dir names on all images,E2,E2,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
FN_LINK_001,File Name,Hard Links,"Hard-link support is gated by BOOT-SECTOR volume-flag bit 0x20 (VBR+0x2C), read once at mount - not by a checkpoint flag, and not confined to v3.14. Static: in all five v3.14-era builds InitializeVcbFromBootSector writes VCB+0x2acc = ((VBR+0x2c >> 5) & 1) | 0x38, and RefsHardlinksSupported is exactly 'return *(short*)(VCB+0x2acc) == 0x39'; RefsSetLinkInfo returns 0xC00000BB when it is false, and RefsCommonQueryVolumeInfo ORs 0x400400 into the FS attributes when true. No checkpoint field appears anywhere in that path. In win10 (v3.4) both the symbol and offset 0x2acc are absent from the entire decompilation and its own InitializeVcbFromBootSector never writes a hard-link field - genuine absence, established by reading the writer rather than by failing to find a name. Disk: over 152 images the two candidate gates do NOT co-vary. Three volumes carry VBR bit 0x20 SET with CHKP+0x78 bit 0x080 CLEAR and all three hold hard links - win1121h2test (v3.7) 74 backings with >=2 back-pointers, win1122h2test (v3.9) 84, win1122h2test_afteropenedwithinsider 169.",PRADE-ART;WININT,,3.4,3.4;3.14,High,No,ENRICHED,"Win10: HardLinkCount=1 always, no RefsLinkFileToSelf. Win11: 40+ hardlink functions (RefsHardlinksSupported, RefsLinkFileToSelf, RefsOpenHardlinkDirectoryTarget, RefsConvertToStandardInfoLinkCount)",INFERRED,"Win11 specials: 182 hardlink files, 33 shared-OID groups; the '110 true hard links' count was a PARSER ARTIFACT (RETRACTED #292/E33 — split type-0x30 value+0x08 is the home-dir backref shared by siblings). Genuine hard links use the split-record mechanism in FN_LINK_002/#340. Win10 specials: 0 hardlink files (CreateHardLink fails). Upgraded 3.4->3.14: no hard links (flag 0x080 absent) | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was ENRICHED): The specific 'CHKP flag 0x080 required' part is a checkpoint/driver gate (E2), not measured here - it is INFERRED at the disk layer. The supported-vs-abolished behavior is disk-consistent.",E2,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,no,INFERRED,prior_work,3.4,3.4;3.14,
AP_LGTB_001,Application,Logfile Info Table,0x10/0x8: start offset of data area,LEE-JRN,p.4,3.4,3.4,High,No,NOT_TESTED,,CONFIRMED,MLog data area start confirmed via control page field at offset 0xB8,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
AP_LGTB_002,Application,Logfile Info Table,0x18/0x8: end offset of data area,LEE-JRN,p.4,3.4,3.4,High,No,NOT_TESTED,,CONFIRMED,MLog data area end confirmed via control page field at offset 0xC0,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
AP_LGTB_003,Application,Logfile Info Table,0x20/0x8: size of data area,LEE-JRN,p.4,3.4,3.4,High,No,NOT_TESTED,,CONFIRMED,Data area size = end - start; varies by volume size and activity level,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
AP_LGTB_004,Application,Logfile Info Table,0x28/0x8: LCN of first control entry,LEE-JRN,p.4,3.4,3.14,High,No,CONFIRMED,verify_static.py: decompiled code / function catalog evidence,CONFIRMED,Control page 0: PLCN 0x30(3.4) or 0x8000(3.14),N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.14,
AP_LGTB_005,Application,Logfile Info Table,"value+0x20 (u64): LCN of the second MLog control entry. The Logfile Information Table (OID 0x9) key=1 row is 0x48 bytes - header 0x18, key u32 = 1, then a 48-byte value: start_lcn +0x00, end_lcn +0x08, size +0x10, control-0 LCN +0x18, control-1 LCN +0x20 (= row+0x38). The page it names carries signature 'MLog' with record type 1 on 13 of 13 volumes.",LEE-JRN,p.4,3.4,3.14,High,No,CONFIRMED,verify_static.py: decompiled code / function catalog evidence,CONFIRMED,"RD, 13 volumes. The second control LCN is NOT version-keyed: 0x31 on win10refsmini (v3.4) AND on win11refs2tsnapshots, win11refs2tspecials, winsider and win11refs110g (all v3.14); 0x24001 on win10refs110g and 0x44001 on win10refs2tspecials (v3.4); 0x18001 on lab314_main and win11refstestmftecmd, 0x1801 on lab314_64k, 0x801 on win11refs5g64k, 0x2c001 on win11refs8g; 0x8001 on win11refsmini ONLY. Do not use the value as a version discriminator. LCN 0x8001 is an MLog DATA record (type 2) on five volumes and reads all zeros on five others.",N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.14,
AP_LGFL_001,Application,Logfile,"Entry Header: 120 bytes, starts with 'MLog'",LEE-JRN,p.5,3.4,3.4,High,No,CONFIRMED,MLog string found in binary; CmsDurableLog class (43/40 funcs) implements WAL with MLog entries,ENRICHED,"MLog control page: 16 fields across 256+ bytes. Version always 1, sector_size matches cluster_size. Complete field map documented from 39 images. Extends Lee's 6-field description to 16-field full layout. Merged from AP_LGFL_RA_001",E1,E1,all,no,UNSTATED,prior_work,3.4,3.4,dossier AP_LGFL_001.md: Re-verification verdict STATIC-CITED — **Original audit verdict:** STATIC-CITED  (disk held 0/1 at audit time)  ·  **Registry status:** ENRICHED  ·  **Evidence
AP_LGFL_002,Application,Logfile,"Log Record Header: 56 bytes, checksum",LEE-JRN,p.5,3.4,3.4;3.14,High,No,CONFIRMED,"RE-ATTRIBUTED: the '56 bytes + checksum' is the ENTRY HEADER (Layer 2) at record+0x78 — 56 bytes (64 on Insider) with checksum (8-byte XOR-fold) at entry+0x08 (=page+0x80). Distinct from the equally-56-byte _SmsRedoRecord (Layer 4), which has NO checksum (record_size@+0x00 opcode@+0x04 table_key_path_length@+0x08 object_id@+0x20 flags@+0x2C). The prior note 'per-record checksum not found' is SUPERSEDED — the checksum IS per-record at entry+0x08.",CONFIRMED,probe_logcore_record.py: entry+0x08 checksum varies per record (win11 0xfa2a568b/0x163223eb/0x1becc9a9) while page+0x04 magic is constant. Inner _SmsRedoRecord still >= 0x38. See finding #319.,E2,E2,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
AP_LGFL_003,Application,Logfile,Log Record: contains redo records with opcodes,LEE-JRN,p.5,3.4,3.4;3.14,High,No,CONFIRMED,CmsLogRedoQueue (33/38 funcs) processes redo records; PerformRedo function replays opcodes via dispatch table (v3.4: 29 values/29 handlers; v3.14: 44 values/43 handlers+1 error branch 0x17 (corrected #328)),CONFIRMED,refs_mlog.py parses redo records from two-layer structure (_SmsRedoHeader → _SmsRedoRecord) on 25/25 images. All opcodes match E2 dispatch tables. Replaces broken refs_logfile.py (E10).,E2,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
AP_LGFL_004,Application,Logfile,"Control Data: sequence number, start/end, next LSN, UUID",LEE-JRN,p.5,3.4,3.4,High,No,CONFIRMED,verify_static.py: decompiled code / function catalog evidence,CONFIRMED,"Control page contains: sequence(0x20), UUID(0x10), data start/end(0xB8/0xC0), LSN range(0xC8/0xD0)",N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4,
AP_LGFL_005,Application,Logfile,ReFS is redo-only (no undo operations),LEE-JRN;PRADE-TR,p.4;p.47,3.4,3.4;3.14,High,No,CONFIRMED,CmsRestarter: 2-pass recovery (AnalyzePass + RedoPass) with no undo pass. 29 funcs (Win10) / 28 (Win11). CoW means old pages intact — undo unnecessary. See CmsRestarter.md,CONFIRMED,No undo-related structures found in MLog control or data areas across all 39 images,E2,E2,all,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
AP_REDO_001,Application,Redo Opcodes,0x00: OpenTable (v3.4) / OpenTableFromTablePath (v3.14),DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,PerformRedo dispatch in both Win10 and Win11. Renamed between versions,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_002,Application,Redo Opcodes,0x01: RedoInsertRow,DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Unchanged across versions,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_003,Application,Redo Opcodes,0x02: RedoDeleteRow,DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Unchanged across versions,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_004,Application,Redo Opcodes,0x03: RedoUpdateRow,DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Unchanged across versions,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_005,Application,Redo Opcodes,"0x04: RedoUpdateDataWithRoot (v3.4 AND v3.14 - dispatched in both). Disk, win11refs2tsnapshots (v3.14): 4,976 opcode-0x04 records of 18,850, across 4,706 of 9,273 merged redo blocks in 2,274 MLog data pages. Abundant on v3.4 too: win10refsmini 87 of 246, win10refs8g 4,656 of 9,818.",DECOMP,PerformRedo,3.4,3.4,High,No,CONFIRMED,"Dispatched in EVERY decompiled build, not removed in v3.14. PerformRedo reads the opcode at param_2+0x04 and routes 4 to RedoUpdateDataWithRoot in all six: win10 3.4 (PerformRedo 1c00e8278, callee 1c00eaec0), 26100.8115 (14012e65c / 140131f98), 26100.8521 (14012e66c / 140131fa8), 26100.8972 (14012dd3c / 140131678), 26100.9444 (14012e0bc / 1401319f8), insider 29574 (14014fda8 / 14015336c). The v3.14 form reads: if (uVar2 != 4) { return -0x3ffffbd9; } lVar4 = RedoUpdateDataWithRoot(...) -- so opcode 4 reaches the handler and never falls to the default error branch. Presence established BY NAME in each build's function index, not inferred from absence of a call site.",NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4,3.4,
AP_REDO_006,Application,Redo Opcodes,0x05: RedoReparentTable,DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Unchanged across versions,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_007,Application,Redo Opcodes,0x06: RedoAllocate,DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Unchanged across versions,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_008,Application,Redo Opcodes,0x07: RedoFree,DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Unchanged across versions,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_009,Application,Redo Opcodes,0x08-0x09: RedoSetRangeState (v3.14 only — gap in v3.4),DECOMP,PerformRedo,3.14,3.14,High,No,CONFIRMED,New in v3.14; both values dispatch to same handler,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.14,3.14,
AP_REDO_010,Application,Redo Opcodes,0x0A: RedoDuplicateExtents,DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Unchanged across versions,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_011,Application,Redo Opcodes,0x0B: RedoModifyStreamExtent,DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Unchanged across versions,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_012,Application,Redo Opcodes,0x0C: RedoStripMetadataStreamExtent (v3.4) / CmsStream::StripAllChecksums (v3.14),DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Repurposed: checksum handling refactored between versions,NOT_TESTED,,E2,E2,all,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_013,Application,Redo Opcodes,0x0D: RedoSetIntegrity (v3.4) / CmsBPlusTable::SetIntegrityInformation (v3.14),DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Renamed between versions; same operation,NOT_TESTED,,E2,E2,all,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_014,Application,Redo Opcodes,0x0E: RedoSetParentId,DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Unchanged across versions,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_015,Application,Redo Opcodes,0x0F: RedoDeleteTable,DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Unchanged across versions,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_016,Application,Redo Opcodes,0x10: CmsBPlusTable::SetObjectRecordPayload (v3.4 AND v3.14 — dispatched in both; disk: 243x on v3.14),DECOMP,PerformRedo,3.4,3.4,High,No,CONFIRMED,Present in v3.4 dispatch; removed in v3.14,NOT_TESTED,,E2,E2,all,no,NOT_TESTED,prior_work,3.4,3.4,
AP_REDO_017,Application,Redo Opcodes,0x11: RedoAddSchema,DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Unchanged across versions,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_018,Application,Redo Opcodes,0x12: RedoMoveContainer,DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,v3.4: goto shared handler; v3.14: direct dispatch. Same operation,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_019,Application,Redo Opcodes,0x13: RedoAddContainer,DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Unchanged across versions,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_020,Application,Redo Opcodes,0x14: RedoMoveContainer (v3.4 AND v3.14 — dispatched in both; driver PerformRedo has 0 gaps),DECOMP,PerformRedo,3.4,3.4,High,No,CONFIRMED,Present in v3.4 dispatch; removed in v3.14,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4,3.4,
AP_REDO_021,Application,Redo Opcodes,0x15: RedoMoveContainer goto (v3.4) / dispatch flag (v3.14),DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,v3.4: goto shared MoveContainer; v3.14: sets dispatch mode flag,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_022,Application,Redo Opcodes,0x16: RedoReadCacheInvalidation (v3.4) / RedoSetRangeState (v3.14),DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Repurposed: read cache removed in v3.14; replaced by range state,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_023,Application,Redo Opcodes,0x17: RedoGenerateChecksum (v3.4) / explicit error NTSTATUS 0xC0000427 (v3.14 — the generic unhandled-opcode error),DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,v3.4: valid handler; v3.14: PerformRedo:239 returns -0x3ffffbd9 = 0xC0000427 (NOT STATUS_LOG_CORRUPTION/0xC01A0003 — CORRECTED 2026-06-18 per J1; was a stale audit false positive).,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_024,Application,Redo Opcodes,0x18: RedoContainerCompression (v3.4) / RedoContainerCompaction (v3.14),DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Renamed between versions; same operation,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_025,Application,Redo Opcodes,0x19: RedoDeleteCompressionUnitOffsets,DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Unchanged across versions,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_026,Application,Redo Opcodes,0x1A: RedoAddCompressionUnitOffsets (v3.4) / RedoGhostExtents (v3.14),DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Repurposed: compression offsets replaced by ghost extents,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_027,Application,Redo Opcodes,0x1B: RedoGhostExtents (v3.4 AND v3.14 — dispatched in both; driver PerformRedo has 0 gaps),DECOMP,PerformRedo,3.4,3.4,High,No,CONFIRMED,Present in v3.4; operation moved to 0x1A in v3.14,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4,3.4,
AP_REDO_028,Application,Redo Opcodes,0x1C: RedoCompactionUnreserve,DECOMP,PerformRedo,3.4;3.14,3.4;3.14,High,No,CONFIRMED,Unchanged across versions,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
AP_REDO_029,Application,Redo Opcodes,0x1D: CmsBPlusTable::UnlinkParentObjectId (v3.14 only),DECOMP,PerformRedo,3.14,3.14,High,No,CONFIRMED,New in v3.14. Hard link removal via parent ID unlink,NOT_TESTED,,E2,E2,all,no,NOT_TESTED,prior_work,3.14,3.14,
AP_REDO_030,Application,Redo Opcodes,"0x1E: CmsTableSetBase::PrepareEntryForMerge (v3.14 only — disk-confirmed; corrected #328, RedoUpdateStreamSummary is 0x1F)",DECOMP,PerformRedo,3.14,3.14,High,No,CONFIRMED,New in v3.14. Prepares stream summary data for 0x1F,NOT_TESTED,,E2,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,no,NOT_TESTED,prior_work,3.14,3.14,
AP_REDO_031,Application,Redo Opcodes,"0x1F: RedoUpdateStreamSummary (v3.14 only — disk-confirmed; corrected #328, UpdateStreamUserPayload is 0x20)",DECOMP,PerformRedo,3.14,3.14,High,No,CONFIRMED,New in v3.14. Updates stream summary,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.14,3.14,
AP_REDO_032,Application,Redo Opcodes,0x21: RedoStreamPersistFastRunInsertion (v3.14 only),DECOMP,PerformRedo,3.14,3.14,High,No,CONFIRMED,New in v3.14. Persist fast run insertion,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.14,3.14,
AP_REDO_033,Application,Redo Opcodes,0x22: RedoTableSetSummaryUpdate (v3.14 only),DECOMP,PerformRedo,3.14,3.14,High,No,CONFIRMED,New in v3.14. Table set summary update,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.14,3.14,
AP_REDO_034,Application,Redo Opcodes,0x23: RedoTableSetShadowTreeUpdate (v3.14 only),DECOMP,PerformRedo,3.14,3.14,High,No,CONFIRMED,New in v3.14. Shadow tree update in table set,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.14,3.14,
AP_REDO_035,Application,Redo Opcodes,0x24: RedoTableSetCommitMerge (v3.14 only),DECOMP,PerformRedo,3.14,3.14,High,No,CONFIRMED,New in v3.14. Commit merge in table set,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.14,3.14,
AP_REDO_036,Application,Redo Opcodes,0x25: RedoTableSetStrongRefMerge (v3.14 only),DECOMP,PerformRedo,3.14,3.14,High,No,CONFIRMED,New in v3.14. Strong reference merge,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.14,3.14,
AP_REDO_037,Application,Redo Opcodes,0x27: RedoSetDefaultCompressionParameters (v3.14 only),DECOMP,PerformRedo,3.14,3.14,High,No,CONFIRMED,New in v3.14. Set compression config,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.14,3.14,
AP_REDO_038,Application,Redo Opcodes,0x28: CmsBlockRefcount::BreakWeakReferences (v3.14 only — decomp PerformRedo_win11 @358); 0x29: RedoDuplicateCluster (v3.14 only — decomp @365),DECOMP,PerformRedo,3.14,3.14,High,No,CONFIRMED,New in v3.14. 0x28 prepares data for 0x29; both dispatch to same handler,NOT_TESTED,,E2,E2,all,no,NOT_TESTED,prior_work,3.14,3.14,
AP_REDO_039,Application,Redo Opcodes,0x2A: RedoChangeRangeEncryptedState (v3.14 only),DECOMP,PerformRedo,3.14,3.14,High,No,CONFIRMED,New in v3.14. Per-range encryption state change,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.14,3.14,
AP_EVNT_001,Application,Event Patterns,File creation: 0x01->0x04->0x01->0x00->0x04->0x01->0x00,LEE-JRN,p.7,3.4,3.4,High,Yes,NOT_TESTED,Lee's v3.4 opcodes: 0x01=InsertRow 0x04=UpdateDataWithRoot 0x00=OpenTable — plausible CREATE pattern. refs_mlog.py --parse classifies CREATE from OpenTable+InsertRow+SetParentId. Verification possible on v3.4 images.,ENRICHED,Lee's pattern matches WRITE transactions (163x on 3 v3.4 images): INSERT UPD_DATA SET_OBJREC OPEN UPD_DATA INSERT OPEN = 0x01 0x04 0x10 0x00 0x04 0x01 0x00. 6/7 opcodes match Lee (position 3: 0x10 vs Lee's 0x01). Actual CREATE is a separate prior transaction: OPEN OPEN UPD_DATA SET_OBJREC INSERT INSERT INSERT SET_PARENT (35x). Lee likely described create-with-content as single operation.,E2,E2,,no,UNSTATED,prior_work,3.4,3.4,dossier AP_EVNT_001.md: Re-verification verdict STATIC-CITED — **Original audit verdict:** STATIC-CITED  (disk held 0/1 at audit time)  ·  **Registry status:** ENRICHED  ·  **Evidence
AP_EVNT_002,Application,Event Patterns,File deletion: 0x0F->0x02->0x0F->0x02->0x04,LEE-JRN,p.7,3.4,3.4,High,Yes,NOT_TESTED,Lee's v3.4 opcodes: 0x0F=DeleteTable 0x02=DeleteRow 0x04=UpdateDataWithRoot — plausible DELETE. forefst mlog classifies DELETE only from RedoDeleteTable (0x0F); a bare DeleteRow (0x02) is ENTRY_REMOVE — a rename/move old-name removal not a deletion (2026-07-03 classifier).,CONFIRMED,"RE-MEASURED 2026-09-19 under the driver's framing (E97): HOLDS, with 3x the support. Transactions beginning exactly 0x0F 0x02 0x0F 0x02: win10refs2g 66, win10refsmini 1 (was 'observed 23x across 3 v3.4 images'). CAVEAT ADDED: it is the DOMINANT form, not the only one -- on win10refs2g 26 transactions begin 0x02 0x0F 0x02 0x0F and 7 begin 0x0F 0x02 0x02 0x0F, so the canonical order is 66 of 99 (67%) of the transactions built from those two opcodes. The earlier 'Exact first-4 match' was true of the 23 rows it saw. Lee's trailing 0x04 still appears as a separate MODIFY transaction.",E2,E2,,yes,CONFIRMED,prior_work,3.4,3.4,
AP_EVNT_003,Application,Event Patterns,File modification: 0x06->0x04->0x04->0x04->0x04->0x08,LEE-JRN,p.7,3.4,3.4,Medium,Yes,NOT_TESTED,Lee's v3.4 opcodes: 0x06=Allocate 0x04=UpdateDataWithRoot 0x08=SetRangeState(gap). 0x08 is a gap in v3.4 dispatch. Pattern includes opcodes not in PerformRedo dispatch table.,NOT_TESTED,6-opcode sequence NOT found as single transaction in any v3.4 image. Individual components observed as separate transactions: ALLOC UPD_DATA (36x) + UPD_DATA (205x) + SET_RANGE (97x). Lee may have used different transaction boundary definition or different v3.4 build. Confidence lowered to Medium.,N/A,NONE,,no,NOT_TESTED,prior_work,3.4,3.4,
AP_EVNT_004,Application,Event Patterns,File renaming: 0x02->0x05->0x01->0x04->0x04,LEE-JRN,p.7,3.4,3.4,High,Yes,NOT_TESTED,Lee's v3.4 opcodes: 0x02=DeleteRow 0x05=ReparentTable 0x01=InsertRow 0x04=UpdateDataWithRoot. Pattern contains REPARENT so this is a MOVE (cross-directory) not same-directory rename.,ENRICHED,First 4 opcodes DELETE REPARENT INSERT UPD_DATA match our MOVE pattern (23x): DELETE REPARENT INSERT UPD_DATA SET_OBJREC UPD_DATA INSERT. Core 0x02 0x05 0x01 0x04 confirmed. Lee's 'renaming' is actually a move operation. Same-directory rename uses DELETE DELETE INSERT INSERT (no REPARENT). REFINEMENT 2026-07-03 (RD step6 v3.14): a same-dir RENAME DOES carry RedoReparentTable (0x05) on v3.14 so reparent-presence is NOT a version-robust move/rename signal; forefst mlog now distinguishes them by the parent-directory table OID (old-name DeleteRow.target_oid vs new-name InsertRow.target_oid — same=RENAME diff=MOVE) validated 100% vs FSActivity+USN; the v3.4 'rename=no reparent' pattern was not re-observed (0 renames in the v3.4 corpus images tested — all name-changes were OID-decidable moves).,E2,E2,,no,UNSTATED,prior_work,3.4,3.4,dossier AP_EVNT_004.md: Re-verification verdict STATIC-CITED — **Original audit verdict:** STATIC-CITED  (disk held 0/1 at audit time)  ·  **Registry status:** ENRICHED  ·  **Evidence
AP_EVNT_005,Application,Event Patterns,Directory creation: 0x00->0x00->0x04->0x10->...,LEE-JRN,p.7,3.4,3.4,High,Yes,NOT_TESTED,Lee's v3.4 opcodes: 0x00=OpenTable 0x04=UpdateDataWithRoot 0x10=SetObjectRecordPayload — plausible CREATE. refs_mlog.py --parse classifies CREATE from OpenTable+InsertRow+SetParentId.,CONFIRMED,"RE-MEASURED 2026-09-19 under the driver's framing (E97): HOLDS. Transactions beginning exactly 0x00 0x00 0x04 0x10: win10refs2g 61, win10refsmini 7 (was 'All 35 CREATE transactions across 3 v3.4 images'). The 'all' still essentially holds: 61 of 62 transactions that begin 0x00 0x00 continue 0x04 0x10 on win10refs2g, 7 of 8 on win10refsmini.",E2,E2,,yes,CONFIRMED,prior_work,3.4,3.4,
AP_EVNT_006,Application,Event Patterns,Directory deletion: 0x02->0x02->0x0F->0x02->...,LEE-JRN,p.7,3.4,3.4,High,Yes,NOT_TESTED,Lee's v3.4 opcodes: 0x02=DeleteRow 0x0F=DeleteTable — plausible DELETE. refs_mlog.py --parse classifies DELETE from DeleteTable/DeleteRow.,ENRICHED,Same opcodes {DELETE DEL_TABLE} observed but ordering differs. Dominant pattern (23x): DEL_TABLE DELETE DEL_TABLE DELETE = 0x0F 0x02 0x0F 0x02. Lee: DELETE DELETE DEL_TABLE DELETE = 0x02 0x02 0x0F 0x02. Same opcode composition different ordering — record order within a transaction may vary by context.,E2,E2,,no,UNSTATED,prior_work,3.4,3.4,dossier AP_EVNT_006.md: Re-verification verdict STATIC-CITED — **Original audit verdict:** STATIC-CITED  (disk held 0/1 at audit time)  ·  **Registry status:** ENRICHED  ·  **Evidence
AP_EVNT_007,Application,Event Patterns,Directory renaming: 0x02->0x02->0x01->0x01->0x04->0x04,LEE-JRN,p.7,3.4,3.4,High,Yes,NOT_TESTED,Lee's v3.4 opcodes: 0x02=DeleteRow 0x01=InsertRow 0x04=UpdateDataWithRoot — same-directory rename (no REPARENT unlike AP_EVNT_004).,CONFIRMED,Core pattern DELETE DELETE INSERT INSERT = 0x02 0x02 0x01 0x01 observed 22x across 3 v3.4 images (11x with trailing SET_PARENT + 11x without). Exact first-4 match. Lee's trailing 0x04 0x04 (timestamp updates) appear as separate MODIFY transactions.,E2,E2,,yes,CONFIRMED,prior_work,3.4,3.4,
AP_WIPE_001,Application,Wiping Patterns,12 tools identified by unique opcode patterns in $Logfile,LEE-WIPE,pp.4-7,3.7,not_verified,Medium,Yes,NOT_TESTED,Lee used v3.7. Opcode numbering may differ from E2 dispatch tables (E10). refs_mlog.py --parse + --csv now enable opcode sequence analysis. Requires controlled wipe experiments to validate.,NOT_TESTED,Requires controlled experiments: run each wipe tool on v3.7 image then analyze MLog via refs_mlog.py --parse.,N/A,NONE,,no,NOT_TESTED,prior_work,3.7,unknown,
AP_CHJN_001,Application,Change Journal,Deactivated by default in ReFS,LEE-JRN,p.5,3.4,not_verified,High,No,CONFIRMED,Cannot confirm default state from static analysis alone,CONFIRMED,"verify_usn_claims.py: Fresh image (win11refsmini) has empty OID 0x520 (1 row, no Change Journal entry). Activated image (win11refs4gattributestest2) has 3 rows including ""Change Journal"" file entry with stream_count=3. Journal structure absent by default, appears after explicit fsutil usn createjournal.",N/A,NONE,,yes,CONFIRMED,prior_work,3.4,unknown,
AP_CHJN_002,Application,Change Journal,Uses USN_RECORD_V3 (128-bit file ref vs NTFS V2 32-bit),LEE-JRN,p.4,3.4,3.4;3.14,High,No,CONFIRMED,128-bit file references confirmed throughout driver; 128-bit metadata addresses in Prade's format,CONFIRMED,128-bit keys (8 padding + 8 OID) observed in Object Table across all images,N/A,NONE,,yes,CONFIRMED,prior_work,3.4,3.4;3.14,
AP_CHJN_003,Application,Change Journal,Circular buffer; old entries overwritten,LEE-JRN,p.4,3.4,not_verified,High,No,NOT_TESTED,,NOT_TESTED,,N/A,NONE,,no,NOT_TESTED,prior_work,3.4,unknown,
AP_CHJN_004,Application,Change Journal,Located in File System Metadata/Change Journal,PRADE-TR;LEE-JRN,pp.44;p.3,3.4,not_verified,High,No,CONFIRMED,verify_static.py: decompiled code / function catalog evidence,CONFIRMED,"verify_usn_claims.py: OID 0x520 is ""FS Metadata"" directory (child of root 0x600 per parent-child table). Contains ""Change Journal"" file entry when journal is active. Path confirmed: Root (0x600) / FS Metadata (0x520) / Change Journal.",N/A,NONE,,yes,CONFIRMED,prior_work,3.4,unknown,
GN_ARCH_SA_001,General,Architecture,Two-layer namespace separation: Refs* (1248 funcs) vs Cms*/Ms* (871 core funcs) in Win10; Refs* (1084) vs Cms*/Ms* (552 core classes) in Win11,static_driver,,both,3.4;3.14,High,No,CONFIRMED,Quantitative confirmation not available in literature; Prade describes concept but not function counts,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
GN_IRP_SA_001,General,Architecture,Three-tier IRP dispatch: RefsFsd* (exception frame) -> RefsCommon* (logic) -> Cms* (storage). 13 dedicated + 5 dispatched = 18 handlers (Win10); 13+7=20 (Win11),static_driver,,both,3.4;3.14,High,No,CONFIRMED,IRP dispatch pattern and handler counts not documented in literature,NOT_TESTED,,E2,E2,all,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
GN_HIER_SA_001,General,Architecture,In-memory hierarchy: VCB (per-volume) -> FCB (per-file) -> SCB (per-stream) -> CCB (per-handle). Attribute def table at VCB+0xa00 (Win10) / VCB+0xd90 (Win11),static_driver,,both,3.4;3.14,High,No,CONFIRMED,Internal memory structures not documented in published work,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
GN_BIN_SA_001,General,Binary,Binary growth: refs.sys 1.92MB->3.53MB (+84%); 3959->5818 funcs (+47%); 415->566 imports (+36%); 1562->4445 strings (+185%). PDB-named: 2553(64.5%) / 2565(44.1%) / 2878(44.8%),static_driver,,both,3.4;3.14,High,No,CONFIRMED,Ghidra quick.json total_functions + pdb_named_functions for all 3 binaries,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
MD_SI_SA_001,Metadata,SI,$SI size: Win10=116B (0x74); Win11=124B (0x7C). RefsMapStandardInfo validates minimum size. NOT backward-compatible,static_driver,,both,3.4;3.14,High,No,CONFIRMED,"Win11 SI structure is entirely new finding. v3.7+ extension fields corrected: 0x40=LastUsn, 0x48=UsnJournalId, 0x50=PackedEaSize, 0x54=ReparseTag, 0x58=NextFileId, 0x60/0x68=ExternalFileId_2/3, 0x70=HardLinkCount, 0x74=NextStreamSetId (see E27/E28/E36/E39)",NOT_TESTED,Would need attribute-level parser to verify from raw disk,E2,E2,all,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
MD_ATTR_SA_001,Metadata,Attributes,"7 new Win11 attributes: $EFS, $LXUID, $LXGID, $LXMOD, $LXDEV, $SNAPSHOT, $OBJ_LINK. Total: 17->24 ($PAGE removed 2026-07-05 - misread PE section .rdata$PAGE, not an attribute; errata E63).",static_driver,,3.14,3.4;3.14,High,No,CONFIRMED,None of these attributes documented in published literature,ENRICHED,"CORRECTED 2026-06-19 (E35): $CBW4 removed — it is a fabrication (0 on disk, 0 as a binary string; the ~140 'CBW4' decomp hits are mangled span<4 byte> template names). Was '9 new / 17->26'. | Win11 schema table has 4 more attribute schemas (0x1c0-0x200) than Win10; may correspond to subsets of these 9 new attributes",N/A,NONE,,no,UNSTATED,prior_work,3.14,3.4;3.14,dossier MD_ATTR_SA_001.md: Re-verification verdict STATIC-CITED — **Original audit verdict:** STATIC-CITED  (disk held 0/1 at audit time)  ·  **Registry status:** ENRICHED  ·  **Evidence
GN_ALLC_SA_001,General,Refactoring,Win11 allocator unification: CmsAllocatorBase(42)+CmsGlobalAllocator(43) -> CmsAllocator(106). Allocation zones: 9->13,static_driver,,3.14,3.14,High,No,CONFIRMED,,NOT_TESTED,,E2 (win11+),E2,win11+,no,NOT_TESTED,prior_work,3.14,3.14,
GN_AMGR_SA_001,General,Refactoring,"Win11 RefsAttributeManager class: centralized attribute CRUD (LookupAttribute, CreateAttribute, DeleteAttribute). Win10 was purely procedural",static_driver,,3.14,3.14,High,No,CONFIRMED,,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.14,3.14,
GN_EFS_SA_001,General,Encryption,"Win11 EFS integration: 2->182 encryption functions; imports from cng.sys; $EFS attribute; RefsSetEncryption(38KB), RefsReadRawEncrypted(31KB), RefsWriteRawEncrypted(38KB)",static_driver,,3.14,3.14,High,No,CONFIRMED,,NOT_TESTED,,E2 (win11+),E2,win11+,no,NOT_TESTED,prior_work,3.14,3.14,
GN_HEAT_SA_001,General,Heat Engine,"Win11 heat-based tiering: 2->55 funcs; CmsVolumeHeatEngine + CmsRotatingSkipList; SmsCompressionHeatClass, SmsDecompressionHeatClass, SmsRecompressionHeatClass",static_driver,,3.14,3.14,High,No,CONFIRMED,,NOT_TESTED,No structural difference visible on disableheatgathering image vs default,E2 (win11+),E2,win11+,no,NOT_TESTED,prior_work,3.14,3.14,
GN_COMP_SA_001,General,Compression,Win11 embeds ZSTD(281 funcs) + LZ4(15 raw funcs); replaces Win10 CmsCompressionLZX(7 funcs). ZSTD added at v3.14 alongside existing LZ4. refsutil.exe also embeds 344 library functions,static_driver,,3.14,3.14,High,No,CONFIRMED,function_catalog.csv prefix counts for ZSTD_/LZ4_; Ghidra quick.json confirms,INFERRED,"NORMALIZED 2026-06-19 (was NOT_CONFIRMED: static function-count evidence, no disk-visible structural effect): 4 compression-enabled images parse identically to non-compressed; no visible structural effect at metadata level",E2,E2,,no,INFERRED,prior_work,3.14,3.14,
GN_DEDUP_SA_001,General,Dedup,"Win11 native dedup: 7 new functions (MsIsDedupEnabled, MsDisableDedup, RefsQueryVolumeDedupInfo). CmsBlockRefcount grows 23->27 funcs",static_driver,,3.14,3.14,High,No,CONFIRMED,,INFERRED,"NORMALIZED 2026-06-19 (was NOT_CONFIRMED: static function-count evidence, no disk-visible structural effect): Dedup-enabled image (win11refs8gdedup) shows no structural difference; refsutil dedup returns 'not supported'",E2 (win11+),E2,win11+,no,INFERRED,prior_work,3.14,3.14,
GN_SNAP_SA_001,General,Snapshots,"Win11 snapshot support. The snapshot functions are Refs*StreamSnapshot*: RefsCreateStreamSnapshot, RefsListStreamSnapshots, RefsQueryDeltasStreamSnapshot, RefsCheckStreamSnapshotManagementBuffers, RefsStreamSnapshotManagement. $SNAPSHOT attribute; no SnapshotId field in $SI; 0x50=PackedEaSize. Snapshots link via the type-0xB0 stream index at val[0x44]. NOTE (E108): there is no CStreamSnapshot class symbol in any decompiled build, and the '6 -> 24 functions' count has no witness - both are withdrawn.",static_driver,,3.14,3.14,High,No,CONFIRMED,"E108: corrected by a symbol census over win10 17134, win11 26100.8115/.8521/.8972/.9444 and Insider 29574. no build contains a CStreamSnapshot symbol; the named Refs* functions are what exists.",INFERRED,"Snapshot-enabled image shows no additional root tables or visible structural changes | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was NOT_CONFIRMED): Function-count and class-name claims are static (E2 win11+). Disk confirms snapshots add no new root tables and live as 0xB0 sub-records, consistent with the claim.",E2 (win11+),E2,win11+,no,INFERRED,prior_work,3.14,3.14,
GN_WSL_SA_001,General,WSL,Win11 WSL interop: native $LXUID/$LXGID/$LXMOD/$LXDEV attributes; IRP_MJ_QUERY_EA + IRP_MJ_SET_EA handlers added,static_driver,,3.14,3.14,High,No,CONFIRMED,,NOT_TESTED,No WSL-enabled images tested; would need WSL usage to populate these attributes,N/A,NONE,,no,NOT_TESTED,prior_work,3.14,3.14,
GN_CROT_SA_001,General,Container Rotation,"Win11 container rotation for flash wear leveling: CmsVolumeContainer 72->130 funcs (+81%); RotateContainers, PersistCompactionExtentsNoAbort",static_driver,,3.14,3.14,High,No,CONFIRMED,,NOT_TESTED,,E2 (win11+),E2,win11+,no,NOT_TESTED,prior_work,3.14,3.14,
GN_KSR_SA_001,General,KSR,"Win11 Kernel Soft Restart: 6 imports from ext-ms-win-ntos-ksr-l1-1-1.dll (KsrMdlToMemoryRuns, KsrGetFirmwareInformation, etc.)",static_driver,,3.14,3.14,High,No,CONFIRMED,,NOT_TESTED,,N/A,NONE,,no,NOT_TESTED,prior_work,3.14,3.14,
GN_FOPS_SA_001,General,File Operations,RefsCommonCleanup: LARGEST function (65050B Win10 / 61441B Win11). Handles IRP_MJ_CLEANUP (last handle close). If file marked for deletion performs actual removal via B+-tree row deletion.,static_driver,,both,3.4;3.14,High,No,CONFIRMED,See RefsCommonCleanup.md. PDB + decompilation confirm deletion path,NOT_TESTED,,E2,E2,all,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
GN_FOPS_SA_002,General,File Operations,File create chain: RefsFsdCreate->RefsCommonCreate->RefsCreateFcb(1049B)->RefsInitializeFcbAndStdInfo->RefsSetStandardInfo->MsUpdateDataWithRoot->checkpoint,static_driver,,both,3.4;3.14,High,No,CONFIRMED,,NOT_TESTED,,E2,E2,win10,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
GN_INS_SA_001,General,Insider,Insider build 10.0.29574.1000: 6430 funcs (+10.5% vs Win11); 648 insider-only PDB names; boot volume support,static_driver,,insider,3.4;3.14;insider,High,No,CONFIRMED,,NOT_TESTED,,E2 (all),E2,all,no,NOT_TESTED,prior_work,3.14,3.4;3.14,
GN_INS_SA_002,General,Insider Boot,CmsVolumeAttestation (40 funcs): TPM/certificate attestation; HMAC over checkpoint/log records. CmsRollbackProtection (13 funcs): UEFI NVRAM monotonic counter,static_driver,,insider,3.4;3.14;insider,High,No,CONFIRMED,,NOT_TESTED,,E2,E2,insider,no,NOT_TESTED,prior_work,3.14,3.4;3.14,
GN_INS_SA_003,General,Insider Boot,Embedded SymCrypt (153 funcs) for early boot + MinCrypt (57 funcs) for certificate chain validation before CNG.sys available,static_driver,,insider,3.4;3.14;insider,High,No,CONFIRMED,,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.14,3.4;3.14,
GN_XVER_SA_001,General,Cross-version,Function comparison: 1931 common (exact key match); 1998 Win10-only; 3856 Win11-only,static_driver,,both,3.4;3.14,High,No,CONFIRMED,,NOT_TESTED,,N/A,NONE,,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
GN_IMP_SA_001,General,Imports,Import table: v3.4=415 imports (2 libraries) vs v3.14=566 (7 libraries). +36% growth. New Win11 libraries: cng.sys(15) ext-ms-win-ntos-ksr(6) msrpc.sys(6) ext-ms-win-crypto-xbox(5) ext-ms-win-ntos-clipsp(1). 184 new imports total; 33 removed,static_driver,,3.14,3.14,High,No,CONFIRMED,Ghidra quick.json imports[] arrays for all 3 binaries,NOT_TESTED,,E2,E2,,no,NOT_TESTED,prior_work,3.14,3.14,
GN_OOP_SA_001,General,OOP,"Win11 upper-layer OOP: 13 named C++ classes with 72 methods + ~345 lambda helpers. Win10 was purely procedural (0 classes, 1248 free functions)",static_driver,,3.14,3.14,High,No,CONFIRMED,,NOT_TESTED,,N/A,NONE,,no,NOT_TESTED,prior_work,3.14,3.14,
GN_UTIL_SA_001,General,refsutil,"Win11 refsutil.exe embeds 100 Minstore core functions (CmsBPlusTable, CmsVolume, CmsStream) for offline volume manipulation",static_driver,,3.14,3.14,High,No,CONFIRMED,,NOT_TESTED,,E2 (win11+),E2,win11+,no,NOT_TESTED,prior_work,3.14,3.14,
FS_VBR_RA_002,File System,VBR,0x48-0x57: Extended GUID (per InitializeVcbFromBootSector → VCB+0x33F0). Unique GUID generated per format event. First appears at v3.10 (Win11 23H2). Zero on v3.4/v3.7/v3.9 and upgraded volumes. Same disk formatted twice → different GUIDs confirmed.,raw_analysis;static_driver,,3.10,3.4;3.10;3.14,High,No,CONFIRMED,InitializeVcbFromBootSector copies bs+0x48 to VCB+0x33F0 (decompiled from Insider build). See InitializeVcbFromBootSector.md,CONFIRMED,Verified on 80+ images: all Win10 zeros; 30+ Win11 unique GUIDs; user dual-format test confirms per-format generation; stable across mount/unmount. Static analysis: InitializeVcbFromBootSector copies to VCB+0x33F0,E2 (all),E2,all,yes,CONFIRMED,prior_work,3.10,3.4;3.10;3.14,
FS_CHKP_RA_001,File System,Checkpoint,"CHKP flags (0x78-0x7B) full decomposition: bit 0x002=always set, bit 0x080=native Win11 format (format-time only), bit 0x200=indirect root list mode, bit 0x400=CRC64 metadata checksumming, bits 0x010+0x020+0x100=dedup-specific. 4 observed composite values: 0x002(Win10), 0x602(upgraded), 0x682(native Win11), 0x7b2(Win11+dedup)",raw_analysis,,3.14,3.4;3.14,High,No,CONFIRMED,ValidateCheckpointRecord: flags at CHKP+0x78 checked for 0x200 (indirect root mode) and other bits. See static_analysis_main_v2.md,CONFIRMED,Flags 0x682 for native Win11 vs 0x602 for upgraded Win10. 0x7b2 for dedup volumes. Bit 0x080 absent on upgraded volumes = format-time flag for native 3.14. Bit 0x200 controls root pointer parsing mode (direct vs indirect). Bit 0x400 correlates with CRC64 metadata checksumming (from ValidateCheckpointRecord SA). Bits 0x010/0x020/0x100 appear only on dedup-enabled volumes. See report_checkpoint_deep_analysis.md,E2,E2,,yes,CONFIRMED,prior_work,3.14,3.4;3.14,
FS_CHKP_RA_002,File System,Checkpoint,"CHKP root reference sizes: 0x68(3.4), 0x30(3.14/CRC64), 0x48(3.14/SHA256)",raw_analysis,,both,3.14,High,No,CONFIRMED,"ValidateCheckpointRecord derives NOTHING from the checksum type or version flags. Read in all six builds (win10 17134 CmsVolume::ValidateCheckpointRecord @1c00664c0, 511 bytes; the 3.14/insider builds carry the same body in the lambda at 26100.8115 @1401052ac, called from ValidateCheckpointRecordCallback @140105e10). It does five things: (1) ComputeOrVerifySelfChecksumBlock over the page, passing the self-descriptor words at page+0x58/+0x5C; (2) root count = u32@+0x90, required 4 < count <= page_size>>2; (3) per root, the OFFSET is read from the u32 array at +0x94+4*i and bounded (>= count*4+0x98, <= page_size, offset+0x28 <= page_size, 8-byte aligned); (4) each root's own length = u32 at root+0x24, bounded against page_size; (5) +0x88/+0x8C bounds. The only version-dependent behaviour is an indirection, not a size: when page+0x78 & 0x200 AND CmsVolume::VersionCheck(0x30b), the offsets array base is u32@+0x94 rather than 0x94 (SmsCheckpointRecord::GetGlobalTableOffset @1400b5fbc).",CONFIRMED,Reference size determined by version+checksum combination. 3.14 uses compacted references,E2,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.14,3.14,
GN_ARCH_RA_001,General,Architecture,Three-table real-LCN bootstrap exception: roots 7+8 (Container Table) + root 12 (Small Allocator). All other roots use virtual addressing,raw_analysis,,both,3.4;3.14,High,No,CONFIRMED,"Confirmed by decompilation: CmsVolume::ValidateCheckpointRecord'::__l2::<lambda_1> initializes local array {0xC,7,8} (=Small Allocator 12, Container Table 7, dup 8) and revalidates those 3 global-table roots via GetGlobalTableRoot (3-iteration loop) - win11 refs_win11.decomp.c:217188, win11latest:217188, insider winsider-refs.decomp.c:285226; array absent in v3.4 win10 (older monolithic validator). Real-LCN behaviour also raw-disk-confirmed across the corpus. E2 (prior audit-3 'not located' verdict was a search-scope error - looked at the wrapper, not the lambda)",CONFIRMED,Not documented in Prade or Lee. Prade only mentions Container Table; does not document Small Allocator exception,E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
AP_LGFL_RA_002,Application,Logfile,MLog physical location: PLCN 0x30 (3.4) vs PLCN 0x8000 (3.14). Version-specific relocation,raw_analysis,,both,3.14,High,No,CONFIRMED,CmsDurableLog::WriteLog offset calculation confirms PLCN allocation,CONFIRMED,"3.14 moves MLog to container boundary, freeing early clusters for metadata",E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.14,3.14,
AP_LGFL_RA_003,Application,Logfile,"Log data area contains MSB+ page images (physical logging model, not logical field-level logging)",raw_analysis,,both,3.4;3.14,High,No,CONFIRMED,CmsRestarter::RedoPass replays MSB+ page images from log (physical redo model),CONFIRMED,58-94 MSB+ pages found in log data area scans. CoW + physical page logging = complete page state preserved,E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
FS_OTBL_RA_001,File System,Object Table,"OID 0x30 = Session Activity Table. First appears in v3.10 (Win11 23H2). Stores per-mount-session IO/allocation statistics. Key: FILETIME + sub-ID. Present on all 46 v3.10+/v3.14 images, absent on all 15 v3.4/v3.7/v3.9 images. Created during upgrade of pre-3.10 volumes.",raw_analysis,,v3.10+,3.10;3.14,High,No,CONFIRMED,RefsTelemetryPerfCountersWorker references OID 0x30 session table,ENRICHED,"Deep-decoded via refs_oid30_analysis.py: B+ tree with FILETIME-keyed rows, two value formats (80-byte summary, 44-byte per-category). Correlates with RefsTelemetryPerfCountersWorker in static analysis. Independent of heat gathering. Forensic value: mount session timestamps and activity metrics.",N/A,NONE,all,yes,CONFIRMED,prior_work,,3.10;3.14,"dossier FS_OTBL_RA_001.md: Re-verification verdict CONFIRMED-ALLDISK — OID 0x30 present exactly on v3.10+ : 97/113 total. By version: v3.4 0/13, v3.7 0/1, v3.9 0/2 (ABSENT); v3.10 2/2, v3.14 "
FS_CHKP_RA_003,File System,Checkpoint,3.4->3.14 upgrade: CHKP flags change from 0x002 to 0x602 (adds 0x200+0x400). Ref_size changes from 0x68 to 0x30. New schemas added (union of old+new). Container Table and Small Allocator physically relocated to lower LCNs. ~35-41 checkpoint cycles observed.,raw_analysis,,3.14,3.14,High,No,CONFIRMED,Upgrade behavior; not directly verifiable from driver static analysis,CONFIRMED,Flags 0x002->0x602 confirmed. Ref_size 0x68->0x30. VBR immutable (0x2A/0x2C/0x48 unchanged). Extensive metadata reorganization.,N/A,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
FS_VBR_RA_004,File System,VBR,BitLocker FVE marker '-FVE-FS-' at VBR+0x03 replaces ReFS signature when volume is encrypted,raw_analysis,,both,3.14,High,No,CONFIRMED,"RefsIsBootSectorOurs checks for ""ReFS"" at +0x03; FVE replaces this. ReadBootSectorForMount handles both paths",CONFIRMED,Confirmed on win11refs4gbitlocked. FVE header (eb 58 90 2d 46 56 45 2d 46 53 2d) completely replaces ReFS VBR,E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.14,3.14,
FS_VBR_RA_005,File System,VBR,refsutil fixboot zeroes VBR fields 0x2A-0x57 (serial/container/GUID) — preserves only geometry (sector/cluster/count/version),raw_analysis,,3.14,3.14,High,No,CONFIRMED,refsutil.exe behavior; not in refs.sys driver,INFERRED,"Documented from fixboot test. 29 bytes differ. Container size=0 makes mounting impossible | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): Behavioral STATIC-CITED claim. I cannot run refsutil, but the single fixboot artifact on disk matches every asserted effect (zeroes 0x2A-0x57 incl serial/container/GUID, preserves geometry). Single-image, so INFERRED rather than A",N/A,NONE,,no,INFERRED,prior_work,3.14,3.14,
FS_VBR_RA_006,File System,VBR,"refsutil fixboot sets container_size=0 at offset 0x40, preventing virtual-to-physical address translation",raw_analysis,,3.14,3.14,High,No,CONFIRMED,refsutil.exe behavior; not in refs.sys driver,INFERRED,"Critical finding: without container size the mount code cannot resolve virtual LCNs via container table | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): Behavioral; corroborated on the 1 fixboot image. The 'prevents VLCN->PLCN translation' consequence is logical (container size feeds Translator cpc) but I did not attempt to mount/translate the corrupted image.",N/A,NONE,,no,INFERRED,prior_work,3.14,3.14,
FS_VBR_RA_007,File System,VBR,refsutil fixboot changes checksum selector (0x2A) from 0x02 to 0x00 — mismatches existing CRC64 metadata,raw_analysis,,3.14,3.14,High,No,CONFIRMED,refsutil.exe behavior; not in refs.sys driver,INFERRED,"Volume formatted with CRC64 but fixboot resets to None; integrity check mismatch prevents mount | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): Behavioral; the fixboot 0x2A->0x00 effect is visible on the one fixboot image. 'Mismatches existing CRC64 metadata' is an inference about mount behavior, not re-measured.",N/A,NONE,,no,INFERRED,prior_work,3.14,3.14,
GN_ARCH_RA_002,General,Architecture,NTFS and ReFS both reject ADS on symlink targets — OS limitation not filesystem-specific,raw_analysis,,both,3.4;3.14,Medium,No,CONFIRMED,Empirical observation; not yet verified in driver code,CONFIRMED,Same Set-Content error on symlinks for both NTFS and ReFS during Generate-FSActivitySpecials,N/A,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_DATA_RA_001,Metadata,Data Extents,"Extent entry is 24 bytes: VLCN(4) + VLCN_hi(4) + flags(4) + file_VCN(4) + pad(4) + run_length(4) CORRECTION (E86 / MD_DATA_RA_024): the field at +0x08 is TWO u16s - flags at +0x08 and the RECORD SIZE at +0x0A - not a u32 flags word. Record size is 24 for a plain run and 24 + run*4 when flags bit 0x80 is set (per-cluster CRC32-C follows, 4 bytes each). Reading the pair as one u32 yields (record_size<<16)|flags, which is why every flag constant quoted here begins 0x18 (= 24, the plain record size). Records are laid out 8-BYTE ALIGNED, so the step to the next record is roundup8(record_size). Measured over 48,474 records / 40 images (0 violations) and 30,524 consecutive row pairs (99.6% gap == roundup8(record_size); the rest are unused node space).",raw_analysis,,3.14,3.4;3.14,High,No,NOT_TESTED,On-disk layout observation; not directly verifiable from driver code,CONFIRMED,Confirmed by extraction verification: extent clusters sum matches alloc_size/cluster_size. Tested on 48 images,N/A,NONE,,yes,CONFIRMED,prior_work,3.14,3.4;3.14,
MD_DATA_RA_002,Metadata,Data Extents,"RETRACTED 2026-06-18: the ""single-extent inline shortcut (0x80000002 marker + VLCN@0x04 + cluster_count@0x08)"" is NOT a real structure — it is a misread of the $DATA sub-record header (marker 0x80000002 + descriptor 0x000E0080). Single-extent files use the standard 24-byte extent entry (MD_DATA_RA_001).",raw_analysis,,3.14,3.14,High,No,CONTRADICTED,All-image verification + content-match (see structure_reference §C.4),CONTRADICTED,"Phantom: 31,523 files resolve via the 24-byte stride / 0 via any 16-byte form / 400/400 content matches; the 1 ""hit"" had ""VLCN""=0xE0080 = the descriptor 0x000E0080.",N/A,NONE,,yes,CONTRADICTED,prior_work,3.14,3.14,
MD_DATA_RA_003,Metadata,Data Extents,Hardlinked files share a single type 0x40 extent entry in the original directory's B+-tree [SUPERSEDED by FN_LINK_002/#340: the type-0x30 value+0x00 is a per-directory child ordinal (not a stream_index) and value+0x08 is the home-dir backref],raw_analysis,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,INFERRED,"Remote resolution: follow the home-dir backref (value+0x08) from type 0x30 to find type 0x40 with matching stream_index in that tree | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): This is a behavioral/superseded claim, not a pure byte-layout assertion. The corrected model (value+0x00 = per-dir child ordinal, value+0x08 = home backref) is in FN_LINK_002. Marking INFERRED — the superseding claim FN_LINK_002 i",N/A,NONE,,no,INFERRED,prior_work,3.14,3.14,
MD_DATA_RA_004,Metadata,Data Extents,Type 0x40 key is 24 bytes: attr_type(2)=0x0040 + key_flags(2) + reserved(4) + stream_index(8) + parent_oid(8),raw_analysis,,3.14,3.14,High,No,NOT_TESTED,On-disk layout observation; not directly verifiable from driver code,CONFIRMED,parent_oid = the directory OID containing the extent data. stream_index links type 0x30 to type 0x40,N/A,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
MD_DATA_RA_005,Metadata,Data Extents,"Type 0x40 value main header: file_size at offset +0x58, alloc_size at +0x60, timestamps at +0x28, file_attrs at +0x48",raw_analysis,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,CONFIRMED,Confirmed by matching values between type 0x30 (compact) and type 0x40 (full header) for same file,N/A,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
MD_DATA_RA_006,Metadata,Data Extents,Hardlink directories contain local type 0x40 stub with alloc_size=0 and file_size=0 — extent data only in original directory,raw_analysis,,3.14,3.4;3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,CONFIRMED,Stub serves as placeholder; real extents obtained via remote OID lookup. Both stubs and real entries share the type-0x40 extent key. [Hard-link framing predates FN_LINK_002/#340; the type-0x30 value+0x00 is a per-directory child ordinal],N/A,NONE,,yes,CONFIRMED,prior_work,3.14,3.4;3.14,
CT_CTBL_RA_003,Content,Container Table,Both SHA256 checksums AND 64K clusters cause container row size to increase from 160 to 224 bytes (they do not stack),raw_analysis,,both,3.4;3.14,High,No,CONFIRMED,Row size variation is disk-level observation; not directly visible in code,CONFIRMED,"Confirmed across 64K and SHA256 images. Row sizes: 160 (CRC64+4K), 224 (SHA256 or 64K)",N/A,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
CT_CTBL_RA_004,Content,Container Table,"Container Allocator (root #2, Table ID 0x20) uses VIRTUAL addressing on ALL versions — contradicts Prade suggestion of real addressing for 3.4",raw_analysis,,both,3.4;3.14,High,No,CONFIRMED,CmsVolumeContainer::PinContainerRange performs VLCN→PLCN translation for Container Allocator,CONFIRMED,Tested on all images: root #2 VLCNs resolve through Container Table and differ from PLCNs. Only roots 7+8+12 use real addressing,E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
CT_COMP_RA_001,Content,Compression,Compression configuration NOT visible via fsutil or raw metadata structures — only refsutil compression /q,raw_analysis,,3.14,3.14,High,No,CONFIRMED,Empirical observation; not yet verified in driver code,CONFIRMED,No fsutil fsinfo or metadata field exposes compression status. Must use refsutil compression /q,N/A,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
CT_COMP_RA_002,Content,Compression,"Compression requires dedup engine + background job; refsutil compression /c only sets parameters, does not compress existing data",raw_analysis,,3.14,3.14,High,No,NOT_TESTED,Empirical observation; not yet verified in driver code,CONFIRMED,Confirmed during compression image creation: /c sets params but actual compression happens via dedup engine,N/A,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
FS_VINF_RA_001,File System,Volume Info,"Volume label (key 0x510) is raw UTF-16LE with no length header — first bytes are first character, null-terminated",raw_analysis,,both,3.4;3.14,High,No,CONFIRMED,Empirical observation; not yet verified in driver code,CONFIRMED,Initially misinterpreted as length-prefixed. Corrected in refs_volume_info.py Bug #3,N/A,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
GN_BPT_RA_001,General,B+-tree,B+-tree row header is 16 bytes (not 14 as Prade documents). Extra u16 padding at 0x0E for 8-byte alignment,raw_analysis,,both,3.4;3.14,High,No,CONFIRMED,"CmsBPlusTable row operations use 16-byte header (key_offset at +0x04, value_offset at +0x06, key_length at +0x08)",CONFIRMED,Matches ARIN tool ROW_HDR_3FORMAT '<I6H' = 16 bytes. Prade describes 7 fields totaling 14 bytes but omits alignment padding,E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
GN_DTCT_RA_001,General,Detection,BitLocker and NTFS volumes correctly detected as non-ReFS by all tools (graceful failure with clear error messages),raw_analysis,,both,3.4;3.14,High,No,CONFIRMED,"RefsIsBootSectorOurs validates ""ReFS"" signature at +0x03 — rejects non-ReFS volumes",CONFIRMED,Tested with win11refsbitlocked (-FVE-FS- signature) and win11ntfs (NTFS signature). Tools reject with descriptive errors,E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_ATTR_RA_003,Metadata,File Attributes,FileAttributes flag 0x40000 indicates Extended Attributes present — undocumented by Microsoft,raw_analysis,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,CONFIRMED,Discovered during refs_attributes.py development. WSL files with $LXMOD/$LXUID/$LXGID have this flag set,N/A,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
MD_ATTR_RA_004,Metadata,File Attributes,WSL FIFOs stored as REPARSE_POINT with $LXMOD upper bits encoding file type (FIFO = S_IFIFO 0o010000; observed $LXMOD 0o10644),raw_analysis,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,CONFIRMED,Confirmed on win11refs4gattributes.raw. FIFO type encoded in mode bits within $LXMOD EA value,N/A,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
AP_LGFL_RA_004,Application,Logfile,"MLog data pages = LogCore records with a 0x78 (120)-byte header [sig@0x00 + magic@0x04 (constant-per-volume NOT a CRC; see E42) + version@0x08 + log_block_size@0x0C + UUID@0x10 + counter@0x20 + LSN@0x28 + prevLSN@0x30 + length-in-4K-blocks@0x38/0x3C + entry_offset@0x54=0x78]. CORRECTED from ""56-byte (CRC...)""",raw_analysis,,3.14,both,High,No,CONFIRMED,LogCoreWriteDataRecord/LogInitializeEntryHeader build the 0x78 header; 0x04=magic from handle+0x2fe8 validated by equality (not CRC); real checksum = XOR-fold at entry+0x08 (page+0x80). v3.4/v3.14/Insider identical,CONFIRMED,probe_logcore_record.py RD-verified on 10 images (v3.4/3.7/3.14/upgraded/compression/262K/Insider-4K+64K). 0x04 constant per volume (win11 0x84c1ffcf; win10 0x998da6fd); entry+0x08 checksum varies per record; LSN chains prevLSN[n]==LSN[n-1] pre-wrap,E2,E2,,yes,CONFIRMED,prior_work,3.14,3.4;3.7;3.14,"format_verified 3.4;3.7;3.14;insider recovered 2026-09-09 from the row's own note: ""probe_logcore_record.py RD-verified on 10 images (v3.4/3.7/3.14/upgraded/compression/262K/Insider-4K+64K)"""
AP_LGFL_RA_005,Application,Logfile,"Log wrapping: the MLog data area is a circular buffer, confirmed. An LSN's low 32 bits are the block's own index WITHIN the data area - equal on 450,115 of 450,115 valid MLog blocks over 15 volumes (4 KiB and 64 KiB, v3.4 and v3.14), and 0 blocks carry a low-32 at or beyond the data-area block count. Wrapping shows as a generation increment with the offset restarting at 0: winsider block 0 = LSN 0x6_00000000 with prev_lsn 0x5_0001FFFF (0x1FFFF = the last block of 131,072); millionsofactionsv2 block 0 = 0x3_00000000, prev 0x2_0003FFFF.",raw_analysis,,3.14,3.14,High,No,CONFIRMED,CmsDurableLog wrapping logic: write pointer wraps to beginning of data area when reaching end,CONFIRMED,"RD. Both old numbers reproduce on win11refs2tmillionsofactions but they are not the two quantities the claim compared: its data area is clusters 32,768..294,912 = 262,144 four-KiB blocks, of which 12,738 carry a record and 249,406 are still zero (the log has never filled; generations 1..3). The max LSN low-32 is 41,142 - an index INSIDE the 262,144-block area, so it exceeds the count of WRITTEN blocks, not the area's physical size. LSN read at MLog block +0x28 (forefst parse_mlog_record_header; docs/structures/mlog.md); data-area bounds from the Logfile Information Table key=1 row.",E2,E2,all,yes,CONFIRMED,prior_work,3.14,3.14,
AP_LGFL_RA_006,Application,Logfile,MLog data area LCNs (from OID 0x9 key=1) are physical — no container translation needed. Entire MLog operates in physical address space.,raw_analysis+E2,,both,3.4;3.14,High,No,CONFIRMED,CmsDurableLog reads physical LCNs directly without CmsVolumeContainer translation. OID 0x9 Logfile Information Table stores data area range as physical clusters.,CONFIRMED,refs_mlog.py reads data area pages at physical offsets (no tr.tr() call). All 25 baseline images parse correctly. Discovery contradicted implementation plan which assumed container translation was required.,E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
FS_CHKP_RA_005,File System,Checkpoint,"CHKP 0x88-0x8B: data area end offset. Value = first_root_offset + root_count * ref_size. 0x680 for 3.4 (13x104B refs from 0x138), 0x380 for 3.14 (13x48B refs from 0x110)",raw_analysis,,both,3.4;3.14,High,No,CONFIRMED,ValidateCheckpointRecord computes data area bounds from root_count * ref_size,CONTRADICTED,"Mathematically verified: 3.4: 0x138+13*104=0x680. 3.14: 0x110+13*48=0x380. Serves as bounds check for driver. See report_checkpoint_deep_analysis.md | RE-VERIFIED 2026-06-18 (all-disk): CHKP+0x88 data-area-end is NOT 'first_root_offset + root_count*ref_size'. v3.4: disk=0x680 but 0x94+13*0x68=0x5dc (mismatch). v3.14: disk=0x380/0x388 but 0x94+13*0x30=0x304. The headline VALUES (0x680 v3.4, ~0x380 v3.14, ~0x4d0 SHA256) are ",E2,E2,,yes,CONTRADICTED,prior_work,3.4;3.14,3.4;3.14,
FS_CHKP_RA_007,File System,Checkpoint,CHKP 0x50-0x53: version echo field. Contains 0x00 on Win10 (3.4) and packed version 0x000E0003 on Win11 (3.14),raw_analysis,,both,3.4;3.14,Medium,No,CONFIRMED,CmsVolume::ReadLatestCheckpoint reads version field at checkpoint offset,CONFIRMED,Win10: 0x00000000. Win11 native and upgraded: 0x000E0003 (=3.14 packed as major|minor). See report_checkpoint_deep_analysis.md,E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
FS_CHKP_RA_008,File System,Checkpoint,Root table provenance chain: all 13 root index-to-table mappings confirmed by three independent sources: (1) PDB-named initialization function at that index (2) schema type from B+-tree page header (3) table ID from page header. Bootstrap roots {7 8 12} hardcoded in ValidateCheckpointRecord,static_analysis;raw_analysis,,both,3.4;3.14,High,No,CONFIRMED,"CmsVolume::Start decompilation shows init sequence. Bootstrap roots {12,7,8} confirmed as literal array {0xC,7,8} in the ValidateCheckpointRecord lambda (win11 refs_win11.decomp.c:217186 / win11latest:217188 / insider:285225), consumed by a 3-iteration GetGlobalTableRoot revalidation loop; the roots-7/8/12 real-LCN fact is raw-disk-confirmed. E2. MS_CP_INDEX_PARENTCHILD=4 is E1 string literal",CONFIRMED,All 48 images show invariant root ordering. Schema types and table IDs match at every resolved address,E1,E1,all,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
FS_VBR_RA_009,File System,VBR,Version evolution: 3.7/3.9 structurally identical to 3.4; 3.10 is critical transition (CRC64+indirect roots+compact refs+native flag+version echo+Format GUID+OID 0x30); CHKP flag 0x2000 = insider-only,raw_analysis,,3.7;3.9;3.10;3.14;insider,3.7;3.9;3.10;3.14;insider,High,No,NEW,7 new images from Step 4 version analysis (21H2/22H2/23H2/Insider),INFERRED,"7 new images from Step 4 version analysis (21H2/22H2/23H2/Insider). See sublab_step4_version_analysis.md | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): Multi-part behavioral claim; the VBR-observable parts (CRC64 selector, GUID, native flag, version echo at v3.10) are disk-consistent. Non-VBR parts (indirect roots, compact refs, OID changes) are out of this region's scope -- belo",N/A,NONE,,no,INFERRED,prior_work,3.7;3.9;3.10;3.14,3.7;3.9;3.10;3.14,
FS_CHKP_RA_009,File System,Checkpoint,CHKP flag 0x2000: Windows Insider only (build 29574+). Present on all insider-formatted and insider-upgraded disks. Absent on Win11 24H2 (build 26200). Related to CmsVolumeAttestation/CmsRollbackProtection,raw_analysis,,insider,insider,Medium,No,NEW,6 insider images all have 0x2000 set,CONFIRMED,"6 insider images all have 0x2000 set. See report_checkpoint_deep_analysis.md FORMAT SCOPE (2026-09-20): `format_verified` was 'insider', which names a DRIVER, not a format. Every insider volume in the corpus is ReFS **3.14** (4 of 4 measured; the only 3.15 and 6.66 images are hand-edited version tests, not insider). The behaviour here is produced by the Insider driver 10.0.29574.1000 writing a 3.14-format volume, so the format verified is 3.14 and the driver is the qualifier - they are different axes.",E2 (all),E2,all,yes,CONFIRMED,prior_work,3.14,3.14,
FS_OTBL_RA_002,File System,Object Table,"Object Table row value header decoded: 8xu32 (format=2, reserved, key_off=0x18, val_off=0x30, payload_offset@u32[4], payload_length@u32[5], lsn_offset@u32[6], lsn_segment@u32[7] — E104) + LCN tuple (4xQ) + checksum. B+-tree value_length = 240/248 (legacy) or 80/88 (compact, growing to 104/112 under SHA-256), the compact form introduced at v3.10; upgraded volumes carry mixed sizes.",raw_analysis,,all,3.4;3.7;3.9;3.10;3.14,High,No,CONFIRMED,CmsObjectTable::GetObjectRecordOfIdentifier and MsGetObjectRecordPayload operate on this row format,NEW,"value+0x10 = payload OFFSET, constant per size-family: 200 legacy / 80 compact / 104 compact-SHA-256. value+0x14 = payload length (0 or 8). off+len = driver-copyable payload extent (200/208 legacy) per CmsObjectTable::GetObjectRecordPayload @140118c14 (src = value+u32@0x10; copy u32@0x14 bytes). value_length = payload extent + a 40-byte tail on legacy (240/248); compact has no tail (value_length = off+len). u32[6]+u32[7] are the two halves of a 64-bit LSN (offset, segment), NOT a generation counter = checkpoint virtual clock (E104): the field takes 8-50 DISTINCT values on one volume where a clock has one, and the 2026-07-06 all-disk pass verified the header OFFSETS, not this reading. All-disk verified 2026-07-06: 34603 OT rows across 114 ReFS images, 0 violations; off@0x10 flat within each family; compact size tracks checksum size (80/88 default, 104/112 SHA-256), independent of cluster size.",E2,E2,,yes,CONFIRMED,this_project,3.4;3.7;3.9;3.10;3.14,3.4;3.7;3.9;3.10;3.14,"dossier FS_OTBL_RA_002.md: Re-verification verdict CONFIRMED-ALLDISK — Full OT value header confirmed on 113/113 images: u32 slots from value+0x00 = [0]=0x2(format/schema-ref), [1]=0 reserved"
FS_OTBL_RA_003,File System,Object Table,OID 0xD = Trash Table (CmsTrashTable). Async deleted-file cleanup queue with schema 0xe0d0. CmsTrashTable::InitializeTable sets OID=0xD and calls MsCreateDurableTableObject. Empty (0 rows) on clean volumes.,static_analysis;raw_analysis,,all,3.4;3.14,High,No,CONFIRMED,"CmsTrashTable::InitializeTable decompiled: local_28=0xd, schema=0xe0d0. Win10+Win11 refs.sys both contain CmsTrashTable class",CONFIRMED,OID 0xD present on all 48 images. B+ tree at OID 0xD shows 0 rows on clean volumes. Page has valid MSB+ signature,E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_OTBL_RA_004,File System,Object Table,OID 0x501 = Volume Information Table (failover/duplicate). Created alongside OID 0x500 by InitializeVolumeInfoTable using MsCreateDurableFailoverTableObject with schema 0x150 and count=2.,static_analysis;raw_analysis,,all,3.4;3.14,High,No,CONFIRMED,"InitializeVolumeInfoTable decompiled: MsInitializeWellKnownObjectId(0x500, 0x501), schema=0x150, MsCreateDurableFailoverTableObject",CONFIRMED,OID 0x501 present on all 48 images. Same failover pattern as 0x07/0x08 and 0x09/0x0A,E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_OTBL_RA_005,File System,Object Table,OIDs 0x540/0x541 = Reparse Point Index (primary/failover). Created by InitializeReparseIndexTable using MsCreateDurableFailoverTableObject with schema 0x160. References REFS_REPARSE_INDEX_FILE_NAME. Indexes reparse points by tag+OID for efficient enumeration.,static_analysis;raw_analysis,,all,3.4;3.14,High,No,CONFIRMED,"InitializeReparseIndexTable decompiled: MsInitializeWellKnownObjectId(0x540, 0x541), schema=0x160, ReparseIndexFileReference string",CONFIRMED,OIDs 0x540/0x541 present on all 48 images. Follows same failover pair pattern,E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_SCHM_RA_001,File System,Schema Table,Schema 0xe0d0 = Trash Table. Created by CmsTrashTable::InitializeTable with OID 0xD. Present on all versions (3.4+).,static_analysis;raw_analysis,,all,3.4;3.14,High,No,CONFIRMED,CmsTrashTable::InitializeTable decompiled: schema=0xe0d0,CONFIRMED,Schema 0xe0d0 present on all 48 images,E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_SCHM_RA_002,File System,Schema Table,"Schema 0xe110 = Read Cache Metadata. Created by ResetReadCacheMetadataFile, which exists in win10 17134 (v3.4) ONLY - it is absent from every v3.14-era build, and the 0xe110 constant likewise appears only in the v3.4 decompilation (E108).",static_analysis;raw_analysis,,3.4+,3.7;3.10;3.14,High,No,CONFIRMED,"E108: corrected by a symbol census over win10 17134, win11 26100.8115/.8521/.8972/.9444 and Insider 29574. the row previously scoped this win11+, which is inverted: the symbol is v3.4-only. ReadCache symbols in the v3.14 builds are MsVolumeHasReadCache, RefsQueryExtentReadCache and RefsUpdateReadCache - none of them this one.",CONFIRMED,"[RETRACTED CLAIM] 'Schema 0xe110 absent on v3.4, present on v3.7+' -- refuted by the re-verification that follows | RE-VERIFIED 2026-06-18 (all-disk): claim: '0xe110 ... First appears in v3.7 (Win11 21H2)' — disk: 0xe110 present on every v3.4 image (13/13), i.e. since v3.4, NOT first at v3.7 | K147 (2026-09-20): CONTRADICTED referred to the literature claim '0xe110 first appears in v3.7'. The row's own re-verification refutes that and supports the description: 0xe110 present on every v3.4 image (13/13). Re-measured 2026-09-20 on the current corpus: present on 9/9 v3.4 images and on every version, confirmed independently by `refsanalysis schema` on win10refsmini and win10refs2g. The stale leading sentence ('absent on v3.4. Present on v3.7+') is the retracted claim and is marked as such.",E2 (win11+),E2,win10,yes,CONFIRMED,prior_work,3.4,3.7;3.10;3.14,status describes the statement this row makes (K147)
FS_SCHM_RA_003,File System,Schema Table,"Schema 0xe120 = Candidate Table (dirty range tracking). CCandidateCmsTable class + MsInsertDirtyRangeEntry validation check. First appears in v3.9 (Win11 22H2) - disk-verified: schema 0xe120 present on v3.9 22H2, absent on v3.7 21H2 (E-audit 2026-07-05).",static_analysis;raw_analysis,,3.9+,3.9;3.14,High,No,CONFIRMED,MsInsertDirtyRangeEntry contains validation: if (*(int*)(...) != 0xe120). CCandidateCmsTable constructor references 0xe120,CONFIRMED,"Schema 0xe120 absent on v3.4/v3.7. Present on v3.10+ images | RE-VERIFIED 2026-06-18 (all-disk): claim: '0xe120 ... First appears in v3.10 (Win11 23H2)' — disk: present on v3.9 (Win11 22H2) images win1122h2test.raw + win1122h2test_testchecksum.raw, so first appearance is v3.9",E2 (win11+),E2,win11+,yes,CONFIRMED,prior_work,3.9,3.9;3.14,
FS_SCHM_RA_004,File System,Schema Table,Schema 0xe130 = Heat Engine Persistence Table. CmsVolumeHeatEngine::Initialize creates table via MsCreateDurableTableObject. Persists container heat metrics for tiered storage optimization (compression/decompression/recompression heat classes). Found in Insider refs.sys binary only (not in Win11 26H1 build). First appears v3.10.,static_analysis;raw_analysis,,3.10+,3.10;3.14,High,No,CONFIRMED,CmsVolumeHeatEngine::Initialize in Insider refs.sys: mov dword [rsp+0x30] 0xe130 as param to MsCreateDurableTableObject. Related: Persist LoadFromTable TrimPersistedEntries,CONFIRMED,Schema 0xe130 absent on v3.4/v3.7. Present on v3.10+. Always 0 rows on test volumes (no active tiered storage),E2 (all),E2,all,yes,CONFIRMED,prior_work,3.10,3.10;3.14,
FS_SCHM_RA_005,File System,Schema Table,Schema 0x1b0 = $SNAPSHOT/$NAMED_STREAM attribute (NOT Index Root). Confirmed via RefsQueryStreamsInfo: uVar5 = 0xb0 alongside RtlInitUnicodeString($SNAPSHOT). Type code 0xB0 exists in all driver builds but schema 0x1B0 only registered on disk at v3.14+.,static_analysis;raw_analysis,,3.14+,3.4;3.14,High,No,CONFIRMED,RefsQueryStreamsInfo sets type code 0xb0 with L$SNAPSHOT. 1228 entries across 46 images (28 true snapshots on 9 images + ADS entries). Schema registered in Schema Table only on v3.14+,CONFIRMED,Type code in driver since v3.4 but schema table entry only on v3.14+ disk images,E1,E1,all,yes,CONFIRMED,prior_work,3.14,3.4;3.14,
FS_SCHM_RA_006,File System,Schema Table,Schemas 0x1c0/0x1d0 = $REPARSE_POINT (0xC0) / $EA_INFORMATION (0xD0). NTFS-equivalent type codes reused by ReFS. Min inline 8B. v3.7+. 0xC0: RefsGetReparsePointValue calls LookupAttribute(0xc0). 0xD0: RefsLookupEasOnFile(Ea.c) calls LookupAttribute(0xd0) with _EA_INFORMATION* param.,static_analysis;raw_analysis,,3.7+,3.7;3.10;3.14,High,No,CONFIRMED,"RefsGetReparsePointValue: LookupAttribute(0xc0). RefsCreateReparsePointInternal: CreateAttributeWithValue(0xc0). RefsLookupEasOnFile: LookupAttribute(0xd0), param3=_EA_INFORMATION*",CONFIRMED,"Schemas 0x1c0/0x1d0 absent on v3.4. Present on v3.7+. No instances in directory B+ trees on 80+ images — stored in per-file attribute sets, not visible in Object Table directory entries",E2,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.7,3.7;3.10;3.14,
FS_SCHM_RA_007,File System,Schema Table,"Schema 0x1e0 = $EA (0xE0). Schema 0x1f0 (type 0xF0) = USN change-journal $Max metadata (NTFS $UsnJrnl:$Max: MaximumSize/AllocationDelta/UsnId/LowestValidUsn), an unnamed single-instance attr on the ""Change Journal"" file under OID 0x520 — NOT EFS and NOT $LOGGED_UTILITY_STREAM. CORRECTION: 0xF0 is created by RefsSetupUsnJournal (NOT RefsCreateLoggedUtilityStream, which uses type 0x100), the type-0xF0 ATTRIBUTE code path is v3.4-era (RefsSetupUsnJournal), but the registered SCHEMA entry 0x1f0 is v3.14+ — disk-confirmed absent on all v3.4/v3.7/v3.9/v3.10 schema tables and present on all v3.14/Insider; EFS uses the separate 0x100/0x200 path. Min 32B payload (0x20) + 12B wrapper = 44B.",static_analysis;raw_analysis,,3.4+,3.4;3.7;3.10;3.14,High,No,CONFIRMED,"RefsLookupEasOnFile: LookupAttribute(0xe0). 0xF0: RefsSetupUsnJournal CreateAttribute(0xf0,NULL,0x20) win11 L445618 / win10 RefsCreateAttributeWithValue(0xf0,0x20) L325274; READ via LookupAttribute(0xf0,NULL). RefsMapLoggedUtilityStream/EfsReadEfsData use type 0x100, not 0xF0.",CONFIRMED,"Type 0xF0 observed on exactly 9 images (1 per image, all where USN journal active), always on the Change Journal file under OID 0x520, marker 0x80000001, 44 bytes. MaxSize 32MB/128MB = standard fsutil usn createjournal sizes. v3.14 empirical floor is a sampling artifact (no pre-v3.14 corpus image had USN active).",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4,3.4;3.7;3.10;3.14,
FS_SNAP_RA_001,File System,Embedded Attribute System,"Complete embedded attribute taxonomy with dual-marker system. The genuine embedded-attribute type-code set is EXACTLY 10 codes: 0x38/0x39 ($OBJ_LINK), 0x80 ($DATA), 0x90 ($I30_INDEX), 0xB0 ($SNAPSHOT/ADS), 0xC0 ($REPARSE), 0xD0 ($EA_INFO), 0xE0 ($EA), 0xF0 (USN $Max), 0x100 ($EFS); 0x50/0x60/0xA0 NEVER appear as embedded sub-records. Marker 0x80000001: single-instance (0x80 DATA header/0xC0 REPARSE/0xD0 EA_INFO/0xE0 EA / 0xF0 USN $Max). Marker 0x80000002: multi-instance (0x39 FileRef/0x80 DATA stream/0xB0 Named Stream/0x100 $EFS). 0xB0 format: val[0x04]=0x68=EXTENDED/non-inline (snapshots OR a large >=2KB ADS) vs !=0x68=INLINE (small ADS); val[0x10] is the ADS(0)-vs-snapshot(2) discriminator (E61). 532503 entries (526454 with markers + 6049 unclassified) across 409185 files on 112 images. LOWER BOUND (E73): this census was taken with an outer-level-only embedded parse, which missed attributes held in a child node (4094 further records over 19 images); the counts here are minima, not totals.",raw_analysis;static_analysis,,all (core types 0x39/0x80 since v3.4; 0xF0 USN $Max since v3.4; 0xC0/0xD0 schema v3.7+; 0xB0/0xE0/0x100 schema v3.14+),3.4;3.7;3.14,High,No,CONFIRMED,RefsQueryStreamsInfo: type 0xb0 = $SNAPSHOT. RefsGetReparsePointValue: 0xC0. RefsLookupEasOnFile: 0xD0/0xE0. RefsSetupUsnJournal CreateAttribute(0xf0) (USN $Max). EFS uses type 0x100. Dual-marker system: 0x80000001 single-instance (incl 0xF0) / 0x80000002 multi-instance,CONFIRMED,28 true version snapshots (dsid>0x1000) across 9 images + 1192 inline ADS + 2200 reparse points + 10130 EA entries (WSL $LXUID/$LXGID/$LXMOD/$LXDEV) + 9 type-0xF0 USN $Max (1/image). All schemas 0x1B0-0x200 empirically confirmed. Tool: refs_snapshots.py + dual_marker_scan.py,E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,,3.4;3.7;3.14,
FS_DEL_RA_001,File System,Deletion and Recovery,ReFS file deletion flow: RefsDeleteFile → MsDeleteRow (removes from directory B+ tree) → MsReparentFileToTrash → CmsTrashTable::AddFileTable (OID 0xD queues for cleanup) → background TrashCleanerWorkItemMethod → DeleteFileTable (frees data extents). CoW ensures old directory pages persist. Recovery: (1) Trash Table scan (2) checkpoint comparison (3) orphaned MSB+ page scan. Updated by E64: recovery is two-mode (recovery/--full) and IDENTITY-based (name+create_time); embedded-record files bypass the Trash via RefsDeleteResidentDataScbAndCommit so only split-record files + directories are reparented; live-page + orphan-page B+-tree node slack (FS_DEL_RA_005) is the primary method.,static_analysis;raw_analysis,,all,3.4;3.14,High,No,CONFIRMED,RefsDeleteFile RefsDeleteFileId2 MsDeleteRow MsReparentFileToTrash CmsTrashTable::AddFileTable TrashCleanerWorkItemMethod CmsTrashTable::DeleteFileTable in Insider refs.sys,CONFIRMED,All 66 test images: empty trash tables and identical checkpoints (no recent deletions). 1222 orphaned leaf pages on millionsofactions image but contain allocator rows not directory entries. Tool: refs_deleted.py,E2 (insider),E2,insider,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_VBR_RA_010,File System,VBR,"VBR 0x58-0x1FF: 424-byte trailing area confirmed all-zero on 13 representative images spanning all ReFS versions (3.4-3.14) and configurations (4K/64K/128K clusters, CRC64, SHA256, dedup, insider). No hidden data. True reserved space.",raw_analysis,,all,3.4;3.14;insider,High,No,CONFIRMED,InitializeVcbFromBootSector reads only up to 0x57; nothing beyond accessed,CONFIRMED,Verified on 13 images: win10refs2g win10refs64k win11refsmini win11refs4gattributes win11refs64k win10to11refsupgrade win11refsdedup win11refssha256 win1121h2test win1122h2test win1123h2test insiderefs8g winsider. See ra_step4_12_deep_structure_report.md,E2 (insider),E2,insider,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.7;3.9;3.10;3.14,
FS_SUPB_RA_001,File System,Superblock,SUPB page header fully decoded (0x00-0x4F). Page header version always 2. Reserved fields at 0x08 and 0x18 always zero. Volume signature = XOR of GUID dwords. LCN slots 1-3 always zero (SUPB is single-cluster). Table OID = 0. Gap 0x60-0x67 between Volume GUID and SUPB version confirmed always zero.,raw_analysis,,all,3.4;3.14;insider,High,No,CONFIRMED,CmsVolume::Start reads and validates SUPB page header fields,CONFIRMED,Page header fields verified on 13 images. SUPB 0x60-0x67 zero across all configurations. See ra_step4_12_deep_structure_report.md,E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_CHKP_RA_011,File System,Checkpoint,CHKP 0x7C-0x87: 12-byte reserved field. Prade Table 4.7 labeled these as 'Offset to table references' (0x7C) 'Table reference count' (0x80) and 'Offset to unknown buffer' (0x84). All three are always zero on all 66 images tested (Prade correction).,raw_analysis,,all,3.4;3.14;insider,High,No,CONFIRMED,Field not accessed by ValidateCheckpointRecord — confirmed reserved,CONFIRMED,Verified zero on 13 representative + previously confirmed on 48 images (Step 4.5). See ra_step4_12_deep_structure_report.md,E2,E2,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_CHKP_RA_012,File System,Checkpoint,"CHKP 0x8C: 0x20 (32) OR 0x0 — NOT always 32. CORRECTED 2026-06-18: it co-varies with CHKP+0x88 (both populated=0x20 / both zero=0x0); zeroed on native-v3.14 checkpoints. So '+0x88/+0x8C' is a field-pair, not a static 'max root capacity = 32' constant (no E2 ties it to MS_CHECKPOINT_MAX_ROOTS as a literal).",raw_analysis,,all,3.4;3.14;insider,High,No,CONTRADICTED,"RE-MEASURED 2026-06-18: CHKP+0x8C distinct values {32,0}; 56/226 checkpoint reads (= 28 native-v3.14 images x 2 slots) read 0, joint with 0x88=0. Matches structure_reference §A.4 / finding #339. The earlier 'always 0x20' was RD on a corpus that never observed the zeroed case.",CONTRADICTED,"See structure_reference §A.4, finding #339; both-zero on native v3.14.",N/A,NONE,,yes,CONTRADICTED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
GN_PAGE_RA_001,General,Page Header,Page header LCN tuple (0x20-0x38): MSB+ pages store 4 consecutive cluster LCNs (self self+1 self+2 self+3) for their 4-cluster extent. SUPB and CHKP use only slot 0 (self-block); slots 1-3 are zero. This is because SUPB is fixed at LCN 30 and CHKP locations are stored in SUPB checkpoint references.,raw_analysis,,all,3.4;3.14;insider,High,No,CONFIRMED,Page allocation code writes 4 LCNs at page header +0x20 for multi-cluster pages,CONFIRMED,Verified on 13 MSB+ root table pages from Win11 4K image: all have LCN[1]=Self+1 LCN[2]=Self+2 LCN[3]=Self+3. SUPB/CHKP confirmed zero at slots 1-3. See ra_step4_12_deep_structure_report.md,N/A,NONE,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
GN_PAGE_RA_002,General,Page Header,Page header Table OID (0x48): MSB+ pages store the Object ID of their owning table (e.g. 0x02=Object ID Table 0x0B=Container Table 0x22=Small Allocator). Enables identification of orphaned CoW-discarded pages. SUPB and CHKP have Table OID = 0.,raw_analysis,,all,3.4;3.14;insider,High,No,CONFIRMED,CmsBPlusTable node initialization writes owning table OID at page +0x48,CONFIRMED,Verified on 13 root table MSB+ pages: Table OID matches expected table identity. OID values observed: 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x22. See ra_step4_12_deep_structure_report.md,E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_SECD_RA_001,File System,Security Descriptors,OID 0x530 B+ tree key/value structure decoded. Key (16B): value_size(4)+padding(4)+SecurityId_high(4)+SD_hash(4). Value: hash_echo(4)+count_echo(4)+size_echo(4)+SECURITY_DESCRIPTOR_RELATIVE. SD is self-relative Windows format with Owner/Group SIDs and DACL/SACL.,raw_analysis;static_analysis,,all,3.4;3.14;insider,High,No,CONFIRMED,CmsSecurityDescriptorStream and CmsHashTable classes in refs.sys. InitializeSecurityDescriptorStream creates OID 0x530,CONFIRMED,"Parsed on win11refsmini.raw (12 SDs), win10refs2g.raw (8 SDs), win11refs4gattributes.raw (10 SDs). All SDs have revision=1 SE_SELF_RELATIVE. Tool: refs_security.py",E2,E2,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_SECD_RA_002,File System,Security Descriptors,Per-file SecurityId (at $SI+0x28 = entry offset 0x50) is compound u64: (reference_count << 32) | sd_hash. Lookup in OID 0x530 by matching key[8:12]==SecurityId_high and key[12:16]==SecurityId_low. CmsHashTable provides O(1) hash-based lookup.,raw_analysis;static_analysis,,all,3.4;3.14;insider,High,No,CONFIRMED,CmsHashTable class (18-23 functions) implements hash-based SD lookup,CONFIRMED,Cross-verified: file SecurityId 0x10a9f9562 correctly maps to SD with hash 0x0a9f9562 in OID 0x530 table. Same mapping works on Win10 3.4 and Win11 3.14,E2,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_SECD_RA_003,File System,Security Descriptors,Schema 0x160 naming correction: 0x160 is used by Reparse Point Index (OIDs 0x540/0x541) via InitializeReparseIndexTable not by Security Descriptors (OID 0x530). OID 0x530 uses stream-type table without schema. Schema name 'Security Descriptor' is misleading.,raw_analysis;static_analysis,,all,3.4;3.14;insider,High,No,CONFIRMED,InitializeReparseIndexTable creates 0x540/0x541 with schema 0x160. OID 0x530 created by InitializeSecurityDescriptorStream separately,INFERRED,"OID 0x540 B+ tree confirmed using schema 0x160 key structure (24-byte keys). OID 0x530 B+ tree uses different key structure (16-byte keys with hash-based lookup) | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): Pure schema-naming correction; verified against structure_reference (0x530 schema='—', 0x540 schema=0x160). The InitializeReparseIndexTable attribution is E2/static — not byte-checkable. Confirmed consistent, label not independent",N/A,NONE,,no,INFERRED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_REPS_RA_001,File System,Reparse Points,"Reparse Index (OID 0x540/0x541 schema 0x160) key structure decoded (24 bytes): u32 marker 0x80000001 @0 (single-instance embedded-subrecord marker; the ""key_type=0x0001/key_flags=0x8000"" split is just a coincidental LE re-read of this u32) + ReparseTag(u32)@4 + _REFS_FILE_REFERENCE(16B)@8. The 16B file-ref is the file's 128-bit reference: word0 (entry ordinal/file-key, small 2..32) @8, containing-directory OID @0x10 (both from [fcb+0x58]+0xf8/+0x100). DISK-VERIFIED 2026-07-05: every index OID@0x10 matches a reparse file's PARENT directory OID (242/242 across 3 images: mftecmd 93/93, insider 42/42, specials 107/107) -- it is the containing directory's OID, NOT a per-file 'own' OID (ReFS files have none). Value: minimal/empty (pure existence index). ONE row per reparse-bearing OBJECT (FCB), inserted by RefsCreateReparsePointInternal via MsInsertRow(...,0x32), deleted by RefsDeleteReparsePointInternal/RefsRemoveReparsePoint via MsDeleteRow. NO tag filter -- ALL tags indexed (mount/symlink/WSL/etc); enumerate uses a match-ALL cursor.",raw_analysis;static_analysis,,all,3.4;3.14,High,No,CONFIRMED,"DRIVER-VERIFIED 2026-07-05 (E2): RefsCreateReparsePointInternal (win11 @388290, insider @498695) builds key = {0x80000001, param5=tag, [fcb+0x58]+0xf8, [fcb+0x58]+0x100}; RefsGetFirst/NextReparseInfo (win11 @457918/@458037) copy 3x u64 out (24B key); RefsPackFileId (@105663) proves _REFS_FILE_REFERENCE=16B (word0@0, OID@8); RefsIsSystemObjectId/RefsHasSystemName (@103061/@112811) test OID at struct+8. Prior ""not verified in driver code"" now resolved; ParentOID label corrected to file-ref word0.",CONFIRMED,"Parsed on win11refs4gattributes.raw: 162 entries (161 SYMLINK + 1 LX_FIFO 0x80000024 - corrected from AF_UNIX, disk-verified + findings #289/E41). win10refs2g.raw: 3 SYMLINK. Key structure consistent across versions. Tool: refs_reparse.py. Per-OBJECT keying => hard-linked reparse NAMES collapse to fewer index rows; but a per-object collapse alone does NOT reconcile 444-names/330-rows on win11refstestmftecmd (18/85/327 groupings all miss 330 -- batch12 2026-07-05); the residual gap is the OLD reparse walker undercount (DEFECT1/C1: dropped split-record (<=84 B) files), fixed in forefst C1.",E2+RD,E2,all,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_REPS_RA_002,File System,Reparse Points,"WSL stores Linux metadata in Extended Attributes ($LXUID $LXGID $LXMOD $LXDEV) using FILE_FULL_EA_INFORMATION format NOT in reparse data. WSL special files use reparse tags AF_UNIX 0x80000023, LX_FIFO 0x80000024, LX_CHR 0x80000025, LX_BLK 0x80000026 (CORRECTED off-by-one, E41/#341; confirmed on win11refs2gtargeted). $LXDEV = 8 bytes (u32 major + u32 minor); $LXUID/$LXGID/$LXMOD = 4B. WSL symlinks use IO_REPARSE_TAG_LX_SYMLINK (0xA000001D). Requires -o metadata mount option.",raw_analysis;static_analysis,,all,3.14,High,No,CONFIRMED,WSL EA format documented in refs_attributes.py. Windows FILE_FULL_EA_INFORMATION is standard Windows EA chain format,CONFIRMED,EA parsing verified on win11refs4gattributes.raw WSL files. $LXUID/$LXGID/$LXMOD extracted. See ra_step4_3_attributes_report.md and ra_step4_14_reparse_points_report.md,N/A,NONE,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.14,
FS_SUPB_RA_002,File System,Superblock,"SUPB page DOES carry a self-checksum, in its self-descriptor at SUPB+0xD0 (cktype byte +0xF2: 1=CRC32-C on 4K, 2=CRC64 on 64K, 4=SHA-256; digest length +0xF4; stored digest +0xF8) - recomputed and matched on all 26 volumes. SUPB+0x08 is always 0x00000000, but that is not where the checksum lives (E105). SUPB is outside the Merkle-tree chain - it is the root and has no parent to store its checksum, which is precisely why it carries its own.",raw_analysis,,all,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,CONFIRMED,"E105: the earlier reading ('no self-checksum, offset 0x08 always 0') was an E49 frame error - the field was read at an assumed offset, found zero, and the structure declared absent. Verified on win11refsmini: descriptor at 0xD0 carries self-LCN 0x1e (= SUPB_LCN), marker 0x08 at +0xF3, cktype 1 (CRC32-C), digest length 4, stored digest 6bba010c; recomputing with the descriptor region zeroed over exactly one cluster MATCHES. The tool has always verified it and prints 'SUPB primary LCN 0x1e - checksum OK' for the primary and both backups. A5/K033's backup-superblock fallback accepts a copy only if it passes this checksum.",E2+RD,CmsVolume::ComputeOrVerifySelfChecksumBlock,all,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.14,
FS_SUPB_RA_003,File System,Superblock,SUPB corruption is silently repaired during mount by Win11 3.14 driver. Corrupted Volume GUID byte (0x2A→0xD5) at SUPB+0x55 was restored to original value during mount. Repair occurs as part of normal checkpoint update cycle (CoW write of fresh SUPB).,raw_analysis,,all,3.14,High,No,NOT_TESTED,On-disk layout observation; not directly verifiable from driver code,CONFIRMED,Binary comparison: corrupted byte 0xD5 reverted to 0x2A after mount. 82 pages changed during mount. See ra_step4_15_corrupted_metadata_report.md,N/A,NONE,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.14,
FS_SUPB_RA_004,File System,Superblock,SUPB Volume GUID at offset 0x50 (16 bytes) is non-critical for bootstrap. Corrupting the GUID does not prevent mount because the driver locates checkpoints via fixed-offset CHKP LCN pointers at SUPB+0xC0/0xC8 not via the GUID.,raw_analysis,,all,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,CONFIRMED,Corrupted GUID volume mounted and operated normally. All files readable. See ra_step4_15_corrupted_metadata_report.md,N/A,NONE,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.14,
FS_SUPB_RA_005,File System,Superblock,CHKP LCN pointers at SUPB offsets 0xC0 and 0xC8 are the only bootstrap-critical SUPB fields. If both are corrupted the driver cannot find any checkpoint and the volume should fail to mount. CHKP corruption NOT tested.,raw_analysis,,all,3.14,Medium,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,CONFIRMED,Inferred from successful mount with GUID corruption: only CHKP pointers needed for bootstrap chain. See ra_step4_15_corrupted_metadata_report.md,N/A,NONE,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.14,
FS_SUPB_RA_006,File System,Superblock,"Mount on a volume with a DAMAGED primary SUPB self-heals it, and the checkpoint activity below is that repair, not a clean-volume mount. The cited pair differs by exactly ONE 4 KiB block and ONE byte: image offset 0x101e055 = primary SUPB (LCN 0x1E) + 0x55, 0x2A -> 0xD5, inside the 16-byte Volume GUID at SUPB+0x50, which breaks that copy's self-checksum. Mounting then reverts that byte (0xD5 -> 0x2A) and the reopened SUPB cluster is byte-identical to the pristine one; the mount also writes 83 further 4 KiB blocks / 34,782 bytes and advances the CHKP virtual clock 64 -> 91. Do not cite these figures as the cost of a normal mount. The repair is DRIVER-DEPENDENT: byte 0x101e055 reads 0x2A before corruption and 0xD5 after, returns to 0x2A when the volume is opened with v3.14, and stays 0xD5 when it is opened with v3.4 - so the 3.4 driver does not perform this self-heal.",raw_analysis,,all,3.14,Medium,No,NOT_TESTED,On-disk layout observation; not directly verifiable from driver code,CONFIRMED,Observed on win11refsmini_aftercorruption_openedwith314.raw vs baseline. See ra_step4_15_corrupted_metadata_report.md,N/A,NONE,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.14,
MD_TS_RA_001,Metadata,Timestamps,Last access time (offset 0x40 in $SI) updated on read operations when RefsDisableLastAccessUpdate=0. Independent of Last Write Time. Verified: cat ok.txt changed LastAccessTime from 3:30:03 to 3:30:27 while LastWriteTime stayed at 3:30:03.,raw_analysis,,all,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,CONFIRMED,Manual test on win11refs8gtest4timestamps.raw with registry RefsDisableLastAccessUpdate=0. Raw disk verification at offset 0x40. See ra_step4_17_4th_timestamp_report.md,N/A,NONE,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.14,
MD_TS_RA_002,Metadata,Timestamps,Write operations update both Last Write Time (M offset 0x30) and Last Access Time (A offset 0x40) simultaneously to the same value. A write implies access.,raw_analysis,,all,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,INFERRED,"Observed in manual timestamp tests on win11refs8gtest4timestamps.raw. See ra_step4_17_4th_timestamp_report.md | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): The 'write updates both M and A to the same value' is behavioral; partially visible (equal timestamps on written files) but a controlled write-vs-read experiment is needed to assert causation. Offsets confirmed.",N/A,NONE,,no,INFERRED,prior_work,3.4;3.7;3.9;3.10;3.14,3.14,
MD_TS_RA_003,Metadata,Timestamps,ADS (Alternate Data Stream) writes update parent file LastWriteTime AND LastAccessTime. The ADS operation is reflected in the main $SI timestamps.,raw_analysis,,all,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,CONFIRMED,set-content -stream 'adstest' updated parent file M and A timestamps. See ra_step4_17_4th_timestamp_report.md,N/A,NONE,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.14,
MD_TS_RA_004,Metadata,Timestamps,Attribute changes (e.g. setting ReadOnly) update ONLY the metadata change time at offset 0x38. This timestamp is NOT exposed by PowerShell Get-Item (which shows only C M A). Only visible via raw disk analysis or Win32 GetFileInformationByHandleEx.,raw_analysis,,all,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,CONFIRMED,Raw disk: MFT change time 13:33:27 at offset 0x38 vs last access 13:32:09 at offset 0x40. Delta = 1:18 confirming separate update. See ra_step4_17_4th_timestamp_report.md,N/A,NONE,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.14,
MD_TS_RA_005,Metadata,Timestamps,ReFS does NOT support 8.3 short file names. fsutil file setshortname returns 'A local NTFS volume is required'. Format-Volume -ShortFileNameSupport $true returns 'Not Supported'. No RefsSetShortName function exists in refs.sys.,raw_analysis;static_analysis,,all,3.14,High,No,CONFIRMED,No RefsSetShortName function in refs.sys decompilation,CONFIRMED,Tested on win11refs8gtest4timestamps.raw. See ra_step4_17_4th_timestamp_report.md,E2,E2,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.14,
MD_TS_RA_006,Metadata,Timestamps,win11refs8gtest4timestamps.raw volume structure: 244 objects OID range 0x7-0x823. Root OID=0x600 newtests=0x741 viascript3=0x742 v2=0x7AC test=0x707.,raw_analysis,,all,3.14,Medium,No,NOT_TESTED,On-disk layout observation; not directly verifiable from driver code,CONFIRMED,Verified via refs_dataruns.py on win11refs8gtest4timestamps.raw. See ra_step4_17_4th_timestamp_report.md,N/A,NONE,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.14,
MD_DATA_RA_007,Metadata,Data Runs,"Integrity stream extents use variable-stride entries. Checksum page entries (flags=0x1c00d0): 32 bytes (24-byte entry + 8-byte CRC suffix) always run_len=1. Data run entries (flags=0x180040): standard 24 bytes variable run_len. Both types point to real file data. Table header format identical to normal extents. CORRECTION (E86): flags=0x1c00d0 is not a distinct entry kind - it is (record_size 0x1c = 28) | (flags 0xd0), i.e. the run_length==1 instance of the checksummed family. The family is flags 0xd0 with record_size 24 + run*4; runs from 11 to 223 are observed on the corpus (e.g. record_size 916 with run 223). The '8-byte CRC suffix' is a 4-byte CRC32-C plus 4 bytes of 8-byte-alignment padding, which is why the step for the run==1 case is 32 (roundup8(28)). A fixed-stride walk that advances 24 unless the u32 equals 0x1c00d0 therefore MISPARSES any checksummed record with run>1; that is why such files failed their coverage check and reported an undecodable holder until E86.",raw_analysis,,all,3.14,High,No,ENRICHED,On-disk layout observation; not directly verifiable from driver code | SA reconciled 2026-06-20: verify_static evidence is co-occurrence/cited only (NOT function-scoped) after the >=3-regex gate fix; overall verdict rests on the raw_analysis (RD) column.,CONFIRMED,Decoded and verified on 50 integrity sub-records across win11refs2g_setintegritystreams0/1.raw. All entries produce total_run matching needed clusters. refs_dataruns.py updated with variable-stride parser,N/A,NONE,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.14,
MD_USN_RA_001,Metadata,USN Journal,USN Journal version 3 record format on ReFS with 128-bit File IDs. Record lengths range from 96 to 168 bytes depending on file name length.,raw_disk,,3.14,3.14,High,No,CONTRADICTED,On-disk layout observation; not directly verifiable from driver code | SA reconciled 2026-06-20: verify_static evidence is co-occurrence/cited only (NOT function-scoped) after the >=3-regex gate fix; overall verdict rests on the raw_analysis (RD) column.,CONTRADICTED,See ra_step4_18_deep_attribute_analysis_report.md Section 3.1 | RE-VERIFIED 2026-06-18 (all-disk): claimed 'Record lengths range from 96 to 168 bytes'; disk shows 80..312 across the corpus. The 96-168 window is both too high a floor (driver min is 0x50=80) and too low a ceiling (312 observed). structure_reference §C.13 already CORRECTED ,N/A,NONE,,yes,CONTRADICTED,prior_work,3.14,3.14,
MD_USN_RA_002,Metadata,USN Journal,"128-bit File ID structure: upper 8 bytes = the CREATION/home directory OID (the dir the file was created in, frozen across rename and move — NOT necessarily the current parent), lower 8 bytes = the per-directory ordinal. Enables direct mapping from a USN record to a B+-tree location. Refined by E68; move-invariance in MD_USN_RA_006.",raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,NEW,"See ra_step4_18_deep_attribute_analysis_report.md Section 3.2 | REFINED (E68, 2026-08-13): upper half is the creation/home dir OID, frozen across rename+move (RD 1,858 cross-dir moves / 9 imgs, unchanged; Parent file ID @0x18 changes). See MD_USN_RA_006.",N/A,NONE,,yes,CONFIRMED,this_project,3.14,3.14,"dossier MD_USN_RA_002.md: Re-verification verdict CONFIRMED-ALLDISK — 128-bit File ID @+0x08 (16B): lower8@+0x08 = entry index, upper8@+0x10 = table OID. Upper8 resolves to a known directory"
MD_USN_RA_003,Metadata,USN Journal,USN reason code catalog for ReFS operations including Reparse point change 0x100000. Covers file create/delete/modify/rename/attribute change/encryption/sparse/security.,raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,NEW,See ra_step4_18_deep_attribute_analysis_report.md Section 3.3,N/A,NONE,,yes,CONFIRMED,this_project,3.14,3.14,"dossier MD_USN_RA_003.md: Re-verification verdict CONFIRMED-ALLDISK — USN reason@+0x38 catalog observed on disk incl. reparse-point-change 0x100000 (874 records on attributestest2), create 0"
MD_SF_RA_001,Metadata,Sparse Files,"Sparse file creation requires 3-step process on ReFS: (1) create file, (2) fsutil sparse setflag, (3) fsutil sparse setrange.",raw_disk,,3.14,3.14,High,No,ENRICHED,On-disk layout observation; not directly verifiable from driver code | SA reconciled 2026-06-20: verify_static evidence is co-occurrence/cited only (NOT function-scoped) after the >=3-regex gate fix; overall verdict rests on the raw_analysis (RD) column.,NEW,See ra_step4_18_deep_attribute_analysis_report.md Section 4.1,N/A,NONE,,no,UNSTATED,this_project,3.14,3.14,dossier MD_SF_RA_001.md: Re-verification verdict STATIC-CITED — **Original audit verdict:** STATIC-CITED  (disk held 0/1 at audit time)  ·  **Registry status:** NEW  ·  **Evidence:** N
MD_SF_RA_002,Metadata,Sparse Files,Sparse flag appears as Basic info change (0x8000) in USN with attribute changing from 0x20 to 0x220 (adding FILE_ATTRIBUTE_SPARSE_FILE bit 0x200).,raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,NEW,See ra_step4_18_deep_attribute_analysis_report.md Section 4.2,N/A,NONE,,no,UNSTATED,this_project,3.14,3.14,dossier MD_SF_RA_002.md: Re-verification verdict STATIC-CITED — **Original audit verdict:** STATIC-CITED  (disk held 0/1 at audit time)  ·  **Registry status:** NEW  ·  **Evidence:** N
MD_SF_RA_004,Metadata,Sparse Files,Fully sparse files have alloc_size=0 on disk (confirmed via refs_dataruns.py). No clusters allocated for fully sparse content.,raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,NEW,See ra_step4_18_deep_attribute_analysis_report.md Section 4,N/A,NONE,,no,UNSTATED,this_project,3.14,3.14,dossier MD_SF_RA_004.md: Re-verification verdict STATIC-CITED — **Original audit verdict:** STATIC-CITED  (disk held 0/1 at audit time)  ·  **Registry status:** NEW  ·  **Evidence:** N
MD_DEL_RA_001,Metadata,Deletion,$RECYCLE.BIN creation captured in USN with full OID/attribute lifecycle. Created on-demand during first Recycle Bin deletion. Attributes set to Hidden|System|Directory (0x16).,raw_disk,,3.14,3.14,High,No,NOT_TESTED,On-disk layout observation; not directly verifiable from driver code,INFERRED,"See ra_step4_18_deep_attribute_analysis_report.md Section 5.1 | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was NEW): The on-disk presence/structure of $RECYCLE.BIN is confirmed; the USN-capture and attribute-bit (0x16) claims are behavioral/USN-log facts not exercised here.",N/A,NONE,,no,INFERRED,prior_work,3.14,3.14,
MD_DEL_RA_002,Metadata,Deletion,Explorer deletion: $R entry is split-record with target_oid pointing to source directory. $I entry (544 bytes) contains original path + deletion timestamp.,raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,CONTRADICTED,"See ra_step4_18_deep_attribute_analysis_report.md Section 5.2 | RE-VERIFIED 2026-06-18 (all-disk): claimed '$I entry (544 bytes)'; disk shows $I $DATA content is 62-188 bytes (variable, holds the path) - the 544 figure is the fixed NTFS $I size, not the ReFS reality. The 'contains original path + deletion timestamp' and '$R non-resident'",N/A,NONE,,yes,CONTRADICTED,prior_work,3.14,3.14,
MD_DEL_RA_003,Metadata,Deletion,PowerShell Remove-Item permanently deletes files (USN reason 0x80000200) bypassing $RECYCLE.BIN entirely.,raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,INFERRED,"See ra_step4_18_deep_attribute_analysis_report.md Section 5.3 | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was NEW): USN-reason and deletion-path are behavioral; no byte-layout signal to confirm/contradict here.",N/A,NONE,,no,INFERRED,prior_work,3.14,3.14,
MD_EFS_RA_001,Metadata,EFS Encryption,EFS encryption lifecycle: EFS0.LOG created in system metadata directory (OID 0x701). Encryption change reason code 0x00040000 in USN.,raw_disk,,3.14,3.14,High,No,ENRICHED,On-disk layout observation; not directly verifiable from driver code | SA reconciled 2026-06-20: verify_static evidence is co-occurrence/cited only (NOT function-scoped) after the >=3-regex gate fix; overall verdict rests on the raw_analysis (RD) column.,NEW,See ra_step4_18_deep_attribute_analysis_report.md Section 6.1,N/A,NONE,,no,UNSTATED,this_project,3.14,3.14,"dossier MD_EFS_RA_001.md: Re-verification verdict NEEDS-STATIC — EFS metadata exists on disk ($EFS 0x100 sub-record, see EFS_RA_005). But 'EFS0.LOG in OID 0x701' and 'USN change-reason "
MD_EFS_RA_002,Metadata,EFS Encryption,Encrypt-decrypt-encrypt cycle fully tracked via USN; each operation generates new EFS0.LOG entry with new OID entry index.,raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,NEW,See ra_step4_18_deep_attribute_analysis_report.md Section 6.2,N/A,NONE,,no,UNSTATED,this_project,3.14,3.14,dossier MD_EFS_RA_002.md: Re-verification verdict NEEDS-STATIC — Encrypt-decrypt-encrypt USN tracking is an event-sequence claim across multiple lifecycle images; not a static on-disk b
MD_EFS_RA_003,Metadata,EFS Encryption,Encrypted files: stream_count=3 with $EFS named stream. Minimum 4096-byte allocation even for small files. Attribute value changes from 0x20 to 0x4020.,raw_disk,,3.14,3.14,High,No,ENRICHED,On-disk layout observation; not directly verifiable from driver code | SA reconciled 2026-06-20: verify_static evidence is co-occurrence/cited only (NOT function-scoped) after the >=3-regex gate fix; overall verdict rests on the raw_analysis (RD) column.,NEW,See ra_step4_18_deep_attribute_analysis_report.md Section 6.3,N/A,NONE,,yes,CONFIRMED,this_project,3.14,3.14,"dossier MD_EFS_RA_003.md: Re-verification verdict CONFIRMED-ALLDISK — Encrypted files: $EFS named-stream sub-record (type 0x100, MI marker, name='$EFS') present on encrypted images (4 on win"
MD_CS_RA_001,Metadata,Case Sensitivity,Per-directory case sensitivity enabled via fsutil file setcasesensitiveinfo (driver RefsSetCaseSensitiveInfo). On-disk marker = the directory $SI internal_flags (type-0x10 value+0x4c) bit 0x02 (0x02 on a case-sensitive dir; 0x00 on normal dirs; disk-verified). When set the B+-tree bypasses the upcase table and compares keys binary (byte-exact) not case-folded.,raw_disk,,3.14,3.14,High,No,CONFIRMED,driver RefsSetCaseSensitiveInfo/RefsQueryCaseSensitiveInfo + RefsDoesDirHaveNoCaseDifferingNames precondition (win11_4b0558f6); on-disk 0x02 flag is RD,CORRECTED,See ra_step4_18 Section 7.1; on-disk $SI internal_flags 0x02 marker disk-verified 2026-07-30,E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,UNSTATED,corrected,3.14,3.14,dossier MD_CS_RA_001.md: Re-verification verdict STATIC-CITED — **Original audit verdict:** STATIC-CITED  (disk held 0/1 at audit time)  ·  **Registry status:** NEW  ·  **Evidence:** N
MD_CS_RA_002,Metadata,Case Sensitivity,Case-sensitive files get distinct FileIds and distinct type-0x20 FileId-index entries (files have no own OID; #327). Files differing only in case coexist as separate type-0x30 B+-tree keys under binary comparison.,raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,CORRECTED,See ra_step4_18 Section 7.2; corrected 2026-07-30 (distinct FileIds not OIDs; #327),N/A,NONE,,no,UNSTATED,corrected,3.14,3.14,dossier MD_CS_RA_002.md: Re-verification verdict STATIC-CITED — **Original audit verdict:** STATIC-CITED  (disk held 0/1 at audit time)  ·  **Registry status:** NEW  ·  **Evidence:** N
MD_LK_RA_001,Metadata,Links,"Junctions, directory symlinks, and file symlinks all supported on ReFS. All symlink types show 'l' flag in PowerShell Mode column.",raw_disk,,3.14,3.14,High,No,ENRICHED,On-disk layout observation; not directly verifiable from driver code | SA reconciled 2026-06-20: verify_static evidence is co-occurrence/cited only (NOT function-scoped) after the >=3-regex gate fix; overall verdict rests on the raw_analysis (RD) column.,INFERRED,"See ra_step4_18_deep_attribute_analysis_report.md Section 8.1 | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was NEW): Pure RD-observation/behavioral; no measurable byte-layout assertion.",N/A,NONE,,no,INFERRED,prior_work,3.14,3.14,
MD_LK_RA_002,Metadata,Links,Symlinks stored as embedded-record entries with attributes 0x420 (file) or 0x10000400 (directory). Target path stored twice in sub-record #3. Reparse data in sub-record #3.,raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,NEW,See ra_step4_18_deep_attribute_analysis_report.md Section 8.2,N/A,NONE,,no,UNSTATED,this_project,3.14,3.14,dossier MD_LK_RA_002.md: Re-verification verdict NEEDS-STATIC — Symlink resident-entry attributes (0x420 file / 0x10000400 dir) and 'target path stored twice in sub-record #3' need a p
MD_LK_RA_003,Metadata,Links,ADS cannot be set on symlink files (reparse points) on ReFS. set-content -stream fails on reparse point entries.,raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,CONFIRMED,See ra_step4_18_deep_attribute_analysis_report.md Section 8.4,N/A,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
MD_LK_RA_004,Metadata,Links,USN reason 0x100000 (Reparse point change) identifies link creation events. Junctions get separate event; symlinks combine with File create (0x00100100).,raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,INFERRED,"See ra_step4_18_deep_attribute_analysis_report.md Section 8.3 | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was NEW): USN-log behavioral; no byte-layout signal.",N/A,NONE,,no,INFERRED,prior_work,3.14,3.14,
MD_SNAP_RA_001,Metadata,Stream Snapshots,"Stream snapshots: the snapshot NAME lives in the type-0xB0 sub-record KEY at key+0x10, not in the value. Key form: u64 0x74 | marker 02 00 00 80 | type b0 00 | subtype 05 00 | name (UTF-16LE). On win11refs2tsnapshots, 10 snapshot sub-records across 5 files (all in dir OID 0x73c) put the name in the key on 10 of 10, and 0 of 10 names occur anywhere in the 116-byte VALUE - the value carries the stream summary (flags u16@+0x10 == 2, sizes at +0x20/+0x28, sub_id). Created via refsutil streamsnapshot /c.",raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,NEW,See ra_step4_18_deep_attribute_analysis_report.md Section 10.1,N/A,NONE,,yes,CONFIRMED,this_project,3.14,3.14,dossier MD_SNAP_RA_001.md: Re-verification verdict CONFIRMED-ALLDISK — On win11refs2tsnapshots.raw the snapshot 0xB0 sub-record stores its name inline as UTF-16LE in the sub-record key starti
MD_SNAP_RA_002,Metadata,Stream Snapshots,Snapshots preserve complete extent descriptor sets for each file version. Enables recovery of previous file content from raw disk.,raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,INFERRED,"See ra_step4_18_deep_attribute_analysis_report.md Section 10.3 | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was NEW): Behavioral/recovery claim; the descriptor structure is on-disk but the extent-backed recovery path is not exercised by corpus images.",N/A,NONE,,no,INFERRED,prior_work,3.14,3.14,
MD_SNAP_RA_003,Metadata,Stream Snapshots,Extent-backed snapshot extents use same VLCN format as type 0x40 data runs. Standard extent resolution applies to snapshot data recovery. CAVEAT (E62): a snapshot of a stream MODIFIED after snapshotting is CoW-shared and recovers only its OWN changed-region extents (len < stream_size) not the full version.,raw_disk,,3.14,3.14,High,No,CONFIRMED,"E2 2026-06-18: snapshot DATA reuses CmsStream::LookupAllocation -- the SAME extent routine as ordinary type-0x40 file reads (reads run+0x00 VLCN, +0x0C file_vcn, +0x14 run_length); 24-byte extent format VLCN@0x00/flags@0x08/file_vcn@0x0C/run@0x14 identical to type-0x40. Residency = disk-allocated-size at DATA value+0x48 (0=inline, >0=extent-backed).",CONFIRMED,"CONFIRMED ALL-DISK 2026-06-18: 29 of 30 true snapshots are EXTENT-BACKED across 8 images; content byte-exact recovered (arg.txt/test2='arg ument 1', 1 extent; xbpt_beta_sierra_570651.json/versionmodified=3,202,036 B across 8 extents, header GFSAREPLAY). Extent format identical to type-0x40 (C.4). The prior UNCONFIRMABLE re-verify conflated the 116-byte 0xB0-record residency with the linked 0x80-DATA-record residency. See structure_reference C.6.",E2,E2,all,yes,CONFIRMED,prior_work,3.14,3.14,
MD_SNAP_RA_004,Metadata,Stream Snapshots,Snapshot sub-record format: size + header + UTF-16 name + metadata + extents. Stream count increases per snapshot (4-6 for 1-2 snapshots).,raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,NEW,See ra_step4_18_deep_attribute_analysis_report.md Section 10.2,N/A,NONE,,yes,CONFIRMED,this_project,3.14,3.14,dossier MD_SNAP_RA_004.md: Re-verification verdict CONFIRMED-ALLDISK — Snapshot sub-record format confirmed: size + header + UTF-16 name (in key) + metadata + (snapshot) descriptor. On the 2-
MD_ATTR_RA_001,Metadata,File Attributes,"Complete attribute values catalog: 0x10 (dir), 0x16 (hidden+system+dir), 0x20 (archive), 0x220 (sparse+archive), 0x420 (reparse+archive), 0x4020 (encrypted+archive), 0x10000400 (dir+reparse ext).",raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,CONTRADICTED,See ra_step4_18_deep_attribute_analysis_report.md Section 12.1 | RE-VERIFIED 2026-06-18 (all-disk): claimed catalog includes 0x10 (dir) and 0x16 (hidden+system+dir); disk shows 0 occurrences of either - directories carry 0x10000000 (the errata 'dir bit is 0x10000000 not 0x10' pitfall). The other 5 catalog values are present.,N/A,NONE,,yes,CONTRADICTED,prior_work,3.14,3.14,
MD_ATTR_RA_002,Metadata,File Attributes,File attribute bit map with bit 10 (0x400 REPARSE_POINT) and bit 9 (0x200 SPARSE_FILE). Full bit decomposition from bit 0 (ReadOnly) through bit 28 (NO_SCRUB_DATA).,raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,NEW,See ra_step4_18_deep_attribute_analysis_report.md Section 12.2,N/A,NONE,,yes,CONFIRMED,this_project,3.14,3.14,"dossier MD_ATTR_RA_002.md: Re-verification verdict CONFIRMED-ALLDISK — Bit 9 (0x200 SPARSE) and bit 10 (0x400 REPARSE) both present at dirent value+0x40: sparse combo 0x220 observed (1 file),"
MD_UNSUP_RA_001,Metadata,Unsupported Features,"Object IDs (fsutil objectid), short names (fsutil file setshortname), and DAX mode NOT supported on ReFS. Hard-link enumeration (fsutil hardlink list) IS supported on native v3.14 (#340/FN_LINK_002 — verified on win11refs2gtargeted); it was unsupported on v3.4.",raw_disk,,3.14,3.14,High,No,ENRICHED,On-disk layout observation; not directly verifiable from driver code | SA reconciled 2026-06-20: verify_static evidence is co-occurrence/cited only (NOT function-scoped) after the >=3-regex gate fix; overall verdict rests on the raw_analysis (RD) column.,NEW,See ra_step4_18_deep_attribute_analysis_report.md Section 11.1,N/A,NONE,,no,UNSTATED,this_project,3.14,3.14,dossier MD_UNSUP_RA_001.md: Re-verification verdict STATIC-CITED — **Original audit verdict:** STATIC-CITED  (disk held 0/1 at audit time)  ·  **Registry status:** NEW  ·  **Evidence:** N
MD_DISK_RA_003,Metadata,Disk Structure,"Embedded type-0x30 entry layout: stream_count at offset 0x20, file attributes at offset 0x48, file size at offset 0x58.",raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,NEW,See ra_step4_18_deep_attribute_analysis_report.md Section 9.3,N/A,NONE,,yes,CONFIRMED,this_project,3.14,3.14,"dossier MD_DISK_RA_003.md: Re-verification verdict CONFIRMED-ALLDISK — resident value+0x58 == FileSize, 409514/409514 v3.14; E114: it is a CACHED copy of the $DATA size - 623,322/623,326 embedded rows over 117 images, the 4 exceptions stale-low on the winsider pair, where the $DATA record is authoritative"
MD_DISK_RA_004,Metadata,Disk Structure,"Stream count semantics: 1=normal file, 2=sparse or link, 3=EFS encrypted, 4-6=files with stream snapshots.",raw_disk,,3.14,3.14,High,No,NOT_TESTED,On-disk layout observation; not directly verifiable from driver code,CONTRADICTED,"See ra_step4_18_deep_attribute_analysis_report.md Section 9.5 | RE-VERIFIED 2026-06-18 (all-disk): claimed '1=normal, 2=sparse or link, 3=EFS, 4-6=stream snapshots'; disk shows stream_count is a COUNT of embedded streams/snapshot-versions, not a file-type tag. sc=2 is the common case for plain files, not 'sparse or link'. The fixed seman",N/A,NONE,,yes,CONTRADICTED,prior_work,3.14,3.14,
MD_DISK_RA_006,Metadata,Disk Structure,"EFS files on disk: stream_count=3, sub-record #4 contains $EFS named stream (720 bytes) with certificate data (magic bytes $EFS in UTF-16).",raw_disk,,3.14,3.14,High,No,ENRICHED,On-disk layout observation; not directly verifiable from driver code | SA reconciled 2026-06-20: verify_static evidence is co-occurrence/cited only (NOT function-scoped) after the >=3-regex gate fix; overall verdict rests on the raw_analysis (RD) column.,NEW,See ra_step4_18_deep_attribute_analysis_report.md Section 9.7,N/A,NONE,,yes,CONFIRMED,this_project,3.14,3.14,dossier MD_DISK_RA_006.md: Re-verification verdict CONFIRMED-ALLDISK — EFS files (encrypted.txt/encrypted2.txt/testefs2.txt/testefs3.txt on win11refs4gattributestest2; efstest.txt on wininsid
MD_DISK_RA_008,Metadata,Disk Structure,$RECYCLE.BIN on disk: $R entry target_oid=0x7B1 links to source directory. $I metadata file (188 bytes inline) contains original path and deletion timestamp.,raw_disk,,3.14,3.14,High,No,ENRICHED,On-disk layout observation; not directly verifiable from driver code,INFERRED,"See ra_step4_18_deep_attribute_analysis_report.md Section 9.9 | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was NEW): The mechanism is right; 0x7B1 and 188 are per-image samples and must be relabelled as examples.",N/A,NONE,,no,INFERRED,prior_work,3.14,3.14,
MD_DISK_RA_009,Metadata,Disk Structure,Case-sensitive directory on disk: both case variants (e.g. ABC.txt and abc.txt) coexist as separate B+-tree keys with distinct FileIds (files have no own OID; #327).,raw_disk,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,NEW,See ra_step4_18_deep_attribute_analysis_report.md Section 9.10,N/A,NONE,,yes,CONFIRMED,this_project,3.14,3.14,"dossier MD_DISK_RA_009.md: Re-verification verdict CONFIRMED-ALLDISK — On win11refs4gattributestest2 (case-sensitive dir feature), two filename keys differing only in case coexist as distinct"
FS_UPGD_RA_001,File System,Version Upgrade,SUPB is NOT modified during version upgrade; only VBR and CHKP are modified. SUPB retains old self-descriptor length (0x68) even after upgrade to 3.14.,raw_disk,,3.4;3.14,3.4;3.14,High,No,ENRICHED,Empirical observation; not yet verified in driver code,NEW,See sublab_step4_version_analysis.md Section 6,N/A,NONE,,no,UNSTATED,this_project,3.4;3.14,3.4;3.14,dossier FS_UPGD_RA_001.md: Re-verification verdict STATIC-CITED — **Original audit verdict:** STATIC-CITED  (disk held 0/1 at audit time)  ·  **Registry status:** NEW  ·  **Evidence:** N
CT_CTBL_RA_006,Content,Container Table,"Deep container row structure: 160-byte (4K/CRC64) with 13 decoded fields. 224-byte (64K or SHA256) with 128-byte extended area. Universal parsing: CPC at +0x18, CSC at value[len-16:len-8]. Container flags bitmask decoded. Extended area (0x50+) = per-container integrity checksum buffer managed by CmsIntegrityState. Size = num_slots x 16: 4 slots (64B) for CRC64, 8 slots (128B) for SHA256. E2: GetNumAllocatedForContainerEntry + PersistContainerCacheWorker confirm via field_18c. E1: zero on 80+ images except 1 container on win10refs2tspecials. Ref: report_container_and_allocator_tables.md §1.3.1",raw_disk+static,,all,3.4;3.14,High,No,CONFIRMED,report_container_and_allocator_tables.md,CONFIRMED,Extended area decoded as integrity checksum buffer (2026-05-23),E2 (win10),E2,win10,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
CT_ALLC_RA_001,Content,Allocator Table,"Deep allocator row structure: key=[range_start,range_length]. Two value formats: bitmap (24B header + 2048B bitmap; 1=allocated 0=free; free_count=range_len-bits_set; field_22=used_count) and compact (24B; flags=0x2 for fully allocated). Three-tier: Small (real LCN root #12), Medium (virtual root #1), Container (virtual root #2)",raw_disk+static,,all,3.4;3.14,High,No,NEW,report_container_and_allocator_tables.md,NEW,See report_container_and_allocator_tables.md,N/A,NONE,,yes,CONFIRMED,this_project,3.4;3.7;3.9;3.10;3.14,3.4;3.14,"dossier CT_ALLC_RA_001.md: Re-verification verdict CONFIRMED-ALLDISK — Bitmap row=2072B with key=[range_start@0x00,range_length@0x08], free_count@0x10, flags@0x12, header_size@0x14, used_coun"
CT_BKRC_RA_001,Content,Block RefCount Table,"Deep row structure: Key=[StartLCN(u64), BlockCount(u64)]. Value=28B header + BlockCount*u16 refcount array + 4B trailing (2080B for bc=0x400). Header: StartLCN(redundant), BlockCount(redundant), ModificationStamp(u64), TotalRefCount(u32). Array entry bitfield: RefCount(13:0), Flag14(14), Shared(15). TotalRefCount=sum(entry&0x3FFF). Dedup flags 0x8000/0x4000 on dedup volumes. Table exists from v3.4 (empty) but populated only on v3.14+. 1305 rows across 83 images; 1302/1302 sum verification matches",raw_disk,,3.14,3.14,High,No,NEW,ra_step4_24_block_refcount_table_report.md,NEW,"See ra_step4_24_block_refcount_table_report.md | E109: the value-length formula holds for the LONG form only; a 32-byte compact form also exists (2 rows on winsider). 'Populated only on 3.14+' and the dedup semantics are WITHDRAWN as untested - lab314_main is a 3.14 volume with an EMPTY refcount table, which contradicts 'populated'.",N/A,NONE,,yes,CONFIRMED,this_project,3.14,3.14,"dossier CT_BKRC_RA_001.md: Re-verification verdict CONFIRMED-ALLDISK — block-refcount value 0x820; TotalRefCount@0x18=sum, array@0x1C, 230/230"
FS_PCTB_RA_001,File System,Parent-Child Table,"Deep row structure: Key=32B [u64 zero, u64 ParentOID, u64 zero, u64 ChildOID]. Value overlaps key (key_offset==val_offset key_length==val_length). Pure set/index with no payload data; 48-byte rows. Only directories tracked; no multi-parent entries across 31392 entries on 76 images. Schema 0xe040 u32[7]=0x08 = key-comparison-rules selector (8 -> CmsRulesPARENT_CHILD_LINK; NOT a bitfield, E50); value-overlaps-key is a caller-side same-buffer construction (AddParentChildLink), not a schema flag. Format version-invariant v3.4-v3.14",raw_disk,,all,3.4;3.14,High,No,CONFIRMED,"E2 2026-06-19: u32[7] (schema-def +0x1C) = KEY-COMPARISON-RULES selector (enum 1..0x14), NOT a bitfield. RegisterSchema win11 @83852 bounds-checks <0x15 and indexes key-rules table DAT_1401cb370 (GetKeyRulesInternal @102170); 0xe040 -> 8 -> CmsRulesPARENT_CHILD_LINK::CompareKeys; .rdata system-schema table reproduces disk values exactly. value-overlaps-key is caller-side: AddParentChildLink @232562 passes the SAME 32-byte buffer as key+value; InitializeIndexEntry @8710 detects value_ptr<=key_ptr<=value_ptr+len and sets value_offset=key_offset. No schema-flag/bit-0x08 test.",CONFIRMED,"See ra_step4_25_parent_child_table_report.md | CORRECTED 2026-06-19 (E50): u32[7]=0x08 confirmed unique to 0xe040; value-overlaps-key 238/238 PCT rows, 0 on all other tables. Bit-3 hypothesis REFUTED on disk: schema 0x130 (u32[7]=0x9, bit3 set) tables do NOT overlap. u32[7] is a key-rules enum, not a bitfield. See pct_schema_u32_7_2026-06-19.md.",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_SCHM_RA_008,File System,Schema Table,"Complete schema identification: 36 distinct schema IDs (18 system + 18 attribute; corrected from 37/19 — phantom 0xe020/0xe0a0 absent from all disk images). 28 confirmed with name (4 attribute via E2 static analysis, 4 legacy system via E3 structural inference). Naming corrections: 0x160=Reparse Index; 0x1b0=$SNAPSHOT; 0x1c0=$REPARSE_POINT; 0x1d0=$EA_INFORMATION; 0x1e0=$EA; 0x1f0=$LOGGED_UTILITY_STREAM. 4 legacy system schemas named via vdo matching: 0xe050=Object Data Table, 0xe070=Reserved/Placeholder, 0xe0e0=System Directory Entry List, 0xe0f0=System File Stream. 2 schemas remain unknown (2 legacy attribute 0x4/0x6). Schema 0xe140 resolved: Volume Attestation Table (E2: CmsVolumeAttestation::InitializeAttestationTable via MsCreateDurableTableObject; 61 functions in class; confirmed via Insider decompilation 2026-05-25)",raw_disk+static,,all,3.4;3.14,High,No,ENRICHED,ra_step4_22_schema_table_names_report.md + ra_step4_8b §1-2,ENRICHED,"RD. Walking the Schema Table (checkpoint root index 3) on all 113 bootstrappable images, the union of schema KEYS is exactly 36: 18 system (0xe010, e030, e040, e050, e060, e070, e080, e090, e0b0, e0c0, e0d0, e0e0, e0f0, e100, e110, e120, e130, e140) and 18 attribute (0x4, 0x6, 0x110..0x200). '0xe020/0xe0a0 absent from all disk images' is true only of KEYS: 0xe020 IS on disk as value+0x20 of schema key 0x6 on 21 of 113 images (13 v3.4, 1 v3.7, 2 v3.9, 2 v3.10, 3 v3.14), written deliberately by MspInitializeSchemas (win10 @1c0010df0), which sets the descriptor field at struct+0x20 to 0xe020 before calling RegisterSchema. Treat 'vestigial' as 'never a table key', not as 'never written'.",E2 (insider),E2,insider,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,"dossier FS_SCHM_RA_008.md: Re-verification verdict CONFIRMED-ALLDISK — Union of all schema-table keys across 111 images = exactly 36 distinct IDs = 18 system (0xe010,e030,e040,e050,e060,e070,"
FS_OTBL_RA_006,File System,Object Table,"OID monotonic assignment: user OIDs start at 0x700 (hardcoded in MsSetMinimumNewObjectId) and increment sequentially via atomic GenerateIdentifier. OIDs are NEVER reused after deletion (DeleteIdentifier never decrements counter). Gaps = deleted objects. Confirmed on 66+ images and by static analysis across 3 driver versions (128 OID functions decompiled, see FS_OTBL_SA_001-010).",raw_disk;static_driver,,all,3.4;3.14;insider,High,No,ENRICHED,ra_step4_20_refs_chronology_analysis.md + ObjectIdLifecycle.md,ENRICHED,Static proof: GenerateIdentifier(SA_001) atomically increments counter; DeleteIdentifier(SA_009) never decrements; MsSetMinimumNewObjectId(SA_004) hardcodes 0x700 boundary,E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,dossier FS_OTBL_RA_006.md: Re-verification verdict CONFIRMED-ALLDISK — User OID boundary measured on 113/113: OID 0x700 itself is NEVER present (0/113 — it is the reserved hardcoded minimum);
FS_OTBL_RA_007,File System,Object Table,"OID chronology, measured on win11refs4gattributestest2 (the image the source report cites; the sentence previously named none). The object map holds 400 entries in total, of which 387 have an OID in 0x700..0x8F9 - the maximum user OID being exactly 0x8F9. Density is 387/505 = 76.6% on the report's exclusive denominator (387/506 = 76.5% inclusive; 400/506 = 79.1%). The earlier sentence conflated the 400 total entries with the 387 in range, so no denominator made its numbers consistent. 128-bit file ids encode the table OID in the upper 8 bytes and a sequential entry index in the lower 8.",raw_disk,,all,3.4;3.14,High,No,NEW,ra_step4_20_refs_chronology_analysis.md,NEW,See ra_step4_20_refs_chronology_analysis.md,N/A,NONE,,yes,CONFIRMED,this_project,3.4;3.7;3.9;3.10;3.14,3.4;3.14,"dossier FS_OTBL_RA_007.md: Re-verification verdict CONFIRMED-ALLDISK — OID density over the user range (>=0x700) across 113 images: min 0.311, median 0.813, max 1.000 (fresh volumes 100%, wor"
FN_MISC_001,File Name,Entry Blocks,v1.2: 64 KiB entry blocks; v3.2+: different sizes,NORDVIK,p.131,1.2/3.2,,Medium,No,NOT_TESTED,,NOT_TESTED,,N/A,NONE,,no,NOT_TESTED,prior_work,1.2;3.2,unknown,
GN_MISC_001,General,Version Compat,v3.2 and v3.4 structures 'almost identical' (Nordvik),NORDVIK,p.128,3.2/3.4,,Medium,No,NOT_TESTED,,NOT_TESTED,,N/A,NONE,,no,NOT_TESTED,prior_work,3.2;3.4,unknown,
GN_MISC_002,General,Georges Thesis,v1.2 structural analysis with EnCase comparison,GEORGES,,1.2,,Medium,No,NOT_TESTED,,NOT_TESTED,,N/A,NONE,,no,NOT_TESTED,prior_work,1.2,unknown,
MD_DISK_RA_010,Metadata,Directory Entry,Type 0x20 = per-object FileId-resolution index (marker 0x80000020; key = marker@0x00 + FileId u64 @0x08 + 0 @0x10). Value type_flag@0x00: Format A (=0) = child filename UTF-16LE; Format B (=1 v3.4 / =2 v3.7+) = 24B home-dir back-reference. NOT a reverse-index/stream-to-filename lookup (corrects pre-2026-06-12 framing; #299/#333; disk-verified 2026-07-30).,raw_analysis,,3.14,3.14,High,No,CONFIRMED,On-disk layout observation; not directly verifiable from driver code,CORRECTED,See ra_step4_18_deep_attribute_analysis_report.md Section 9.4; corrected per #299/#333,N/A,NONE,,yes,CONFIRMED,corrected,3.14,3.14,"dossier MD_DISK_RA_010.md: Re-verification verdict CONFIRMED-ALLDISK — Type 0x20 entries with kf=0x8000 present on 113/113. Key (24B): attr_type 0x20@+0x00, kf 0x8000@+0x02, reserved 4B@+0x04"
FS_OTBL_SA_001,File System,Object Table,"CmsObjectTable::GenerateIdentifier: atomic OID allocation via LOCK prefix increment at this+0x18. Returns max+1 as new OID in 128-bit SmsBigIdentifier format [0, OID]. Win11/Insider: lock-free atomic; Win10: GuardedMutex at this+0x40. 458 bytes (Insider).",static_driver,,all,3.4;3.14;insider,High,No,CONFIRMED,ObjectIdLifecycle.md §2.1. Cross-version comparison: Win10 uses KeAcquireGuardedMutex(this+0x40); Win11/Insider uses x86 LOCK prefix. Identical counter-increment logic in all versions,CONFIRMED,See ObjectIdLifecycle.md,E2 (all),E2,all,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_OTBL_SA_002,File System,Object Table,"CmsObjectTable::InitializeTable: bootstraps OID counter at mount time. Two-source: (1) reads stored counter from B+-tree root data; (2) validates by FindRow with _CmsKey::RightMost sentinel → returns actual max key. If max key > stored counter, updates to max. Schema 0xe030. 815 bytes (Insider).",static_driver,,all,3.4;3.14;insider,High,No,CONFIRMED,ObjectIdLifecycle.md §2.2. All three versions use identical two-source initialization strategy. _CmsKey::RightMost confirmed as FindRow sentinel in all builds,CONFIRMED,See ObjectIdLifecycle.md,E2 (insider),E2,insider,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_OTBL_SA_003,File System,Object Table,CmsObjectTable::SetMinimumNewObjectId: sets minimum OID boundary. Compares 128-bit proposed minimum with current counter; only updates if proposed > current. Uses PushLock exclusive. 108 bytes (Insider).,static_driver,,all,3.4;3.14;insider,High,No,CONFIRMED,ObjectIdLifecycle.md §2.3. Present in all three versions with identical logic,CONFIRMED,See ObjectIdLifecycle.md,E2 (insider),E2,insider,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_OTBL_SA_004,File System,Object Table,MsSetMinimumNewObjectId: format-time initialization that HARDCODES 0x700 as minimum user OID. Called during volume format. Boundary between system OIDs (0x01-0x6FF) and user OIDs (0x700+). 166 bytes (Insider).,static_driver,,all,3.4;3.14;insider,High,No,CONFIRMED,ObjectIdLifecycle.md §2.4. 0x700 boundary confirmed in all three driver versions,CONFIRMED,See ObjectIdLifecycle.md,E2 (insider),E2,insider,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_OTBL_SA_005,File System,Object Table,RefsIsSystemObjectId: 25-byte function returns true for OIDs in 0x01-0x5FF and 0x601-0x6FF. Root directory (0x600) explicitly excluded from 'system' classification. Boundary at 0x6FF matches MsSetMinimumNewObjectId.,static_driver,,all,3.4;3.14;insider,High,No,CONFIRMED,ObjectIdLifecycle.md §2.5. Identical in all three versions (25 bytes each),CONFIRMED,See ObjectIdLifecycle.md,E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_OTBL_SA_006,File System,Object Table,"MsInitializeWellKnownObjectId: trivial 12-byte helper constructing 128-bit SmsBigIdentifier from a 64-bit well-known OID value (e.g. 0x600=root dir, 0x500=volume info). Sets upper 8 bytes to 0.",static_driver,,all,3.4;3.14;insider,High,No,CONFIRMED,ObjectIdLifecycle.md §2.6,CONFIRMED,See ObjectIdLifecycle.md,E2,E2,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_OTBL_SA_007,File System,Object Table,MsGetObjectRecordPayload: 46-byte helper extracting LcnWithChecksum pointer from Object Table row. Returns pointer to the page reference within the row's value buffer at offset derived from row header.,static_driver,,all,3.4;3.14;insider,High,No,CONFIRMED,ObjectIdLifecycle.md §3.2,CONFIRMED,See ObjectIdLifecycle.md,E2,E2,all,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_OTBL_SA_008,File System,Object Table,RefsOpenFcbById: opens a file by its 128-bit OID. Largest Refs-layer OID consumer (5792B Win11 / 5958B Insider). Call chain: OID lookup → FCB create → RefsMapStandardInfo → security load → RefsOpenFile. Two FCB creation paths (normal + hardlink/special).,static_driver,,3.14;insider,3.14;insider,High,No,CONFIRMED,RefsOpenFcbById.md. Win11 takes explicit _IRP*; Insider uses opaque param (+166 bytes for attestation checks),CONFIRMED,See RefsOpenFcbById.md,E2 (all),E2,all,yes,CONFIRMED,prior_work,3.14,3.14,
FS_OTBL_SA_009,File System,Object Table,"DeleteIdentifier removes an OID from the Object Table B+-tree and does NOT decrement the allocation counter. 110 bytes in Insider 29574, 119 in win11 26100.8115 - not a thin wrapper (E108). That this function does not decrement does not by itself GUARANTEE OIDs are never reused; the no-reuse behaviour is established on disk (gaps equal deletions) and by CmsObjectTable::GenerateIdentifier's atomic increment.",static_driver,,all,3.4;3.14;insider,High,No,CONFIRMED,"E108: corrected by a symbol census over win10 17134, win11 26100.8115/.8521/.8972/.9444 and Insider 29574. the row said '30 bytes (Insider, thin wrapper around DeleteRow)'; measured 110 (Insider) and 119 (win11 26100.8115). The 'guarantees' wording is narrowed to what one function can support.",INFERRED,"See ObjectIdLifecycle.md | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): The observable consequence (no OID reuse, gaps=deletions) is CONFIRMED-ALLDISK via RA_006/RA_007; the function-internal 'no decrement' assertion is INFERRED from those plus E2 static.",E2 (insider),E2,win10;win11.8115;win11.8521;win11.8972;win11.9444;insider,no,INFERRED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
FS_OTBL_SA_010,File System,Object Table,CmsObjectTable::InsertIntoParentChildTable: inserts [parent_OID child_OID] pair into Parent-Child Table (schema 0xe040). Called for every directory entry creation. Enables reverse lookup (find children of a parent). ~280 bytes (Insider).,static_driver,,all,3.4;3.14;insider,High,No,CONFIRMED,ObjectIdLifecycle.md §5.1. Same insert pattern across all versions. Key format: [0 parent_OID 0 child_OID],CONFIRMED,See ObjectIdLifecycle.md,E2 (insider),E2,insider,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.14,
GN_ARCH_SA_002,General,Architecture,DriverEntry initialization: registers IRP dispatch table (IRP_MJ_CREATE/CLEANUP/CLOSE/READ/WRITE/DEVICE_CONTROL/SET_INFORMATION/QUERY_INFORMATION/etc.). Initializes global state and registry configuration. ~7533 bytes Win10.,static_driver,,both,3.4;3.14,High,No,CONFIRMED,See DriverEntry.md. PDB confirms all IRP handler registrations,NOT_TESTED,,E2 (win10),E2,win10,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
FS_VBR_SA_013,File System,VBR,"RefsIsBootSectorOurs: validates boot-sector ownership. Read in all six builds (insider 29574 @1402c5e54, 344 bytes; identical elsewhere but win10 uses VCB+0x198 for the sector-count bound). In order: two global disable flags == 0; device sector size (VCB+0x114) > 0xFF; bytes 3..10 == 'ReFS\0\0\0\0'; 0x57 < u16@+0x14 <= devsec; a ROR1+ADD self-checksum over bytes 3..u16@+0x14-1 skipping +0x16/+0x17, compared with u16@+0x16 - the strongest check in the function; bytes-per-sector at +0x20 in the RANGE 0x200..0x1000 (test: value - 0x200 < 0xe01), NOT a power-of-two test; sectors-per-cluster at +0x24 in the SET {1,4,8,16,32,64,128,256,512} (mask 0x8000000080008089 on spc-1, plus 0x80/0x100/0x200), also not a power-of-two test; u64@+0x18 != 0 AND <= VCB+0x1f0; finally VCB+0x118/0x120 <= spc*devsec. Returns BOOLEAN. Both literals 0xe01 and 0x8000000080008089 occur 2/2 in every build.",static_driver,,insider,3.14,High,No,CONFIRMED,See RefsIsBootSectorOurs.md. Decompiled from Insider build,NOT_TESTED,,E2 (insider),E2,insider,no,NOT_TESTED,prior_work,3.14,3.14,
FN_OPEN_SA_001,File Name,Object Table,RefsCommonCreate: core file/directory create and open logic (~18679/19580 bytes). Calls RefsEditFileBegin which assigns unique OID from Object Table during file creation.,static_driver,,both,3.4;3.14,High,No,CONFIRMED,See RefsCommonCreate.md. PDB + decompilation confirm OID assignment via RefsEditFileBegin,NOT_TESTED,,E2,E2,win10,no,NOT_TESTED,prior_work,3.4;3.14,3.4;3.14,
MD_SI_SA_002,Metadata,SI,"RefsComputeStandardInformationFromFcb (present only in the v3.14-era drivers - win11 26100 and Insider 29574; absent from win10 17134): constructs complete 124-byte $STANDARD_INFORMATION from FCB fields. Maps all $SI offsets (corrected names: LastUsn 0x40, UsnJournalId 0x48, PackedEaSize 0x50, ReparseTag 0x54, NextFileId 0x58, ExtFileId_2/3 0x60/0x68, HardLinkCount 0x70, NextStreamSetId 0x74). Not present in Win10.",static_driver,,3.14,3.14,High,No,CONFIRMED,See RefsComputeStandardInformationFromFcb.md. Rosetta Stone for Win11 $SI structure,NOT_TESTED,Would need attribute-level parser to verify from raw disk,E2,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,no,NOT_TESTED,prior_work,3.14,3.14,
CT_DRNT_RA_001,Content,Data Run Table,Snapshot extent entries use same 24-byte format (VLCN+flags+file_VCN+run_length) as regular type-0x40 data runs. Unified extent storage across non-embedded directory entries and embedded DATA entries. Confirmed on 21 snapshots across 4 images.,raw_analysis;static_driver,,3.14,3.14,High,No,CONFIRMED,Same extent structure visible in CmsStream::LookupAllocation,CONFIRMED,Validated on 12 files / 21 true snapshots / 4 images including 21-extent 13.4 MB chains,E2,E2,all,yes,CONFIRMED,prior_work,3.14,3.14,
CT_CTBL_RA_007,Content,Virtual Addressing,"Address translation shift = CPC.bit_length() = 15 (4K) / 11 (64K), NOT log2(CPC) = 14/10. The driver stores log2(CPC) and adds 1 before shifting - that invariant holds in all six builds - but the FIELD OFFSET is build-specific and must not be quoted as one number: CmsVolume::SetClustersPerContainer writes log2 to volume+0x4C and CPC to +0x50 on win10 17134 (@1c003142c), and log2 to +0x50 with CPC at +0x54 on 26100.8115 (@1400ffe10), .8521, .8972, .9444 and insider 29574 (@140124208). GetContainerIdFromRealRange agrees, shifting by (+0x4C)+1 on win10 and (+0x50)+1 on the rest. So on the 3.4-era driver volume+0x50 holds CPC ITSELF, not log2(CPC).",post_thesis_errata,,both,3.4;3.14,High,Yes,CONFIRMED,Win11 refs.sys decompilation at 0x1400b3e64 confirms +1 shift,CONFIRMED,VLCN 81408 with shift=15 resolves to CID 2 (MSB+ valid); shift=14 gives CID 4 (wrong page). Verified on 20 images,E2+RD,E2,all,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
FS_SCHM_RA_009,File System,Schema Table,"Production v3.14 has 29 schemas (13 system + 16 attribute), not 30 (14+16). 14 system schemas is the Insider count (adds 0xe140 Vol Attestation). Errata E14.",post_thesis_errata,,3.14;insider,3.14,High,Yes,CONFIRMED,schema tool output on 20 images confirms 13/16 split for v3.14 and 14/16 for Insider,CONFIRMED,All 14 v3.14 test images show 29 schemas; Insider shows 30,RD,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
FN_DTBL_005,File Name,Directory Entries,"key_flags is u16 at key+0x02, NOT the first 4 bytes of the row header. Values 0x68/0x2a8 are row sizes. key_flags take ONLY {0x01, 0x02}; 0x04 NEVER appears. The flag encodes RECORD PLACEMENT, not data residency (E77): 0x01 = the name row EMBEDS the object's record; 0x02 = the name row is an INDEX ENTRY whose record was split into a type-0x40 backing in the home directory. Neither value says where the file's data lives - residency must be read from the $DATA attribute's storage. (Measured: every kf=0x01 FILE row is extent-backed on v3.4/3.7/3.9/3.10 - 1120/250/386/236 rows, zero inline; on v3.14 219,960 of 236,769 are inline.) Directories are key_flags 0x02 with the directory attribute bit 0x10000000 set in the value attribute word (value+0x40), NOT a separate 0x04 flag. Distribution 111 images/525K entries: {0x01: 409483 ; 0x02: 115682 ; 0x04: 0}. Errata E15/E17 ""0x04=directory"" was wrong.",post_thesis_errata,,both,3.4;3.7;3.9;3.10;3.14,High,Yes,CONFIRMED,forefst.py reads key type at kd[0:2] and filename at kd[4:]. No code path writes key_flags=0x04; RefsAddFileNameIndexEntry ORs dir bit 0x10000000 into the attribute word.,CONFIRMED,"key_flags distribution {0x01:409483, 0x02:115682, 0x04:0} across 111 images. Directories: kf=0x02 + attrs bit 0x10000000 at value+0x40 (e.g. $RECYCLE.BIN kf=0x02 attrs=0x10000006). E77 (RD 2026-09-02, 99-image corpus): the flag/residency equivalence is falsified; a kf=0x02 FILE row is a move/hard-link fingerprint (51/51 on the audited 2 TB volume), and the form does not exist on v3.4 (0 type-0x40 rows, 0 kf=0x02 file rows).",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.7;3.9;3.10;3.14,
FN_DTBL_006,File Name,Directory Entries,Directory key has no Reserved(4) field at 0x04. Correct: Type(2)+key_flags(2)+Filename(var) starting at offset 0x04. Errata E16.,post_thesis_errata,,both,3.4;3.14,High,Yes,CONFIRMED,forefst.py kd[4:].decode(utf-16-le) produces correct filenames,CONFIRMED,Row size proof: coucou=6 chars -> key=4+12=16B; with Reserved(4) it would be 20B giving 108 not 104=0x68,E2+RD,E2,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
FS_VBR_RA_011,File System,Bootstrap Chain,"VBR format-time fields (0x2A checksum algo, 0x2C volume flags, 0x48 format GUID) are NEVER modified during version upgrade. Upgraded volumes retain original VBR values while CHKP shows new version.",post_thesis_verification,,both,3.4;3.14,High,Yes,CONFIRMED,verify_static.py: decompiled code / function catalog evidence,CONFIRMED,Upgraded image: VBR 0x2A=0x0000/0x2C=0x06/0x48=not set but CHKP version=3.14 flags=0x602. Verified on win10to11refs4g_afterwin11mount.raw,RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
FS_CHKP_RA_013,File System,Bootstrap Chain,"Three forensically distinguishable volume states via CHKP flags: original v3.4 (0x002), upgraded v3.4->v3.14 (0x602), native v3.14 (0x682). Missing bit 0x080 distinguishes upgraded from native.",post_thesis_verification,,both,3.4;3.14,High,Yes,CONFIRMED,verify_static.py: decompiled code / function catalog evidence,CONFIRMED,Verified on 20 images: flag patterns are invariant within each category,RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
FS_SCHM_RA_010,File System,Schema Table,Schema 0x160 = Reparse Index (naming correction). Previously unnamed or mislabeled as Security Descriptor in some contexts.,post_thesis_verification,,3.7+,3.7;3.14,High,Yes,CONFIRMED,Schema tool output shows Reparse Index label from PDB,CONFIRMED,Present in all v3.7+ images; absent in v3.4,E1+RD,E1,,yes,CONFIRMED,prior_work,3.7,3.7;3.14,
FS_SCHM_RA_011,File System,Schema Table,"Schema counts per version verified: v3.4=27(15+12), v3.7=30(15+15), v3.9=31(16+15), v3.10=30(15+15), v3.14=29(13+16), Insider=30(14+16) [E53: the 2 legacy attr schemas 0x04/0x06 on v3.4-v3.10 were previously omitted; all-disk re-measured 2026-06-20]. Complete evolution matrix.",post_thesis_verification,,all,3.4;3.7;3.9;3.10;3.14;insider,High,Yes,CONFIRMED,Schema tool on 6 version-representative images,CONFIRMED,"Exact counts match on all 20 test images | RE-VERIFIED 2026-06-18 (all-disk): claim: v3.4=27(15+12), v3.7=30(15+15), v3.9=31(16+15), v3.10=30(15+15), v3.14=29(13+16), Insider=30(14+16) [E53: the 2 legacy attr schemas 0x04/0x06 on v3.4-v3.10 were previously omitted; all-disk re-measured 2026-06-20] — disk: v3.4=27, v3.7=30, v3.9=31, v3.10=30 (each +2 from omitted legacy 0x004+0x006); v3.14=29 and Insider=30 MATCH | K147 (2026-09-20): the row states per-version schema counts that its own notes record as matching on all 20 test images and RE-VERIFIED all-disk. CONTRADICTED described the superseded claim, not this text.",RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.7;3.9;3.10;3.14,status describes the statement this row makes (K147)
MD_SNAP_RA_005,Metadata,Directory Entries,"E20 RETRACTED: ADS are always inline. 956 ADS across 46 images all have StreamSummary flags=0. 29 snapshot entries have SS flags=2. 28 entries initially misclassified as extent-based ADS were actually snapshots (same 0x000500B0 descriptor). Discriminator: StreamSummary flags (u16) at val[0x10] — 0=ADS, 2=snapshot.",v3.0.5_research,,both,3.4;3.14,High,Yes,CONFIRMED,RefsConvertToNonResident accepts type 0xB0; the 2KB threshold IS reached by a large ADS (>=2KB) which becomes non-resident/extent-backed (type-0x0 record; E61). ADS-always-inline holds only <2KB; the val[0x10] 0=ADS/2=snapshot discriminator is unaffected,CONFIRMED,"985 entries / 111 images: 956 ADS (SS flags=0) + 29 snapshots (SS flags=2). Both discriminators (val[0x10] and val[0x02] HasSnapshot bit) agree perfectly | CORRECTED 2026-09-04 (E87/MD_ADS_RA_003): named streams are NOT always inline. Census of every 0xB0 row - 8,353 rows / 57 images, 0 unrecognised - gives 7,505 inline, 4 empty, 729 EXTENT-backed and 115 snapshot-name entries. The earlier 'always resident' rests on samples that were all small: on format >=3.11 a named stream of 2,048 B or more is never inline, and 13 smaller ones are extent-backed too because their writer pre-allocated (alloc != size, the E60 rule). | 2026-09-04: the val[0x10] discriminator is re-confirmed corpus-wide and from a second direction - every 0xB0 row with val[0x10] == 2 carries a sub-stream id at val+0x44 that matches an existing $DATA sub-id > 0x1000 on the host object, 115 of 115. The 'ADS are always inline' half of this row is corrected by MD_SNAP_RA_007/MD_ADS_RA_003: 729 of 8,238 named streams are extent-backed.",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_SI_RA_001,Metadata,$SI,"E21: $SI field corrections — ReparseTag at +0x54 (not 0x4C), HardLinkCount at +0x70 (not 0x48), +0x48 is conditional u64, +0x50 is u16-derived u32. Five corrections from RefsComputeStandardInformationFromFcb decompilation.",v3.0.5_research,,3.14,3.14,High,Yes,CONFIRMED,"RefsComputeStandardInformationFromFcb: *(u32*)(SI+0x54) = *(u32*)(FCB+0x9c) (ReparseTag), *(u32*)(SI+0x70) from RefsConvertToStandardInfoLinkCount",CONFIRMED,"525K entries / 111 images: +0x54 correct for symlinks. +0x70 always 0 or 1. CORRECTION: the prior ""confirmed cross-directory hard links"" (87/41 multi-parent OIDs) were a parser artifact — split type-0x30 value[0x08] is the home-directory OID back-reference (shared by siblings), not a child OID. $SI+0x70 is the embedded-layout HLC (always 0/1) and is NOT the multi-name counter. The pre-step6 corpus had no genuine hard links, but they DO exist (split type-0x30 mechanism) and were since observed on win11refs2gtargeted (FN_LINK_002/#340)",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.14,3.14,
CT_BKRC_RA_002,Content,Block RefCount,"BRC key = start_lcn(u64) + block_count(u64 always 0x400). Value = 1024 per-cluster u16: bit 15=shared/dedup-managed, bit 14=dedup metadata flag, bits 13:0=reference count (0-505 observed). Value header at +0x18 = TotalRefCount (u32) == Sum(array entry & 0x3FFF), upper 16 bits always 0 (230/230 rows, master B.6).",v3.0.5_research,,3.14,3.14,Medium,Partial,CONFIRMED,BRC table accessed via root #6; key/value structure confirmed in decompilation,CONFIRMED,"CORRECTED 2026-06-19 (master B.6): +0x18 = TotalRefCount = Sum(entry&0x3FFF), re-confirmed 230/230 rows 2026-06-17. The earlier 'compound field / 67/97 violations / not simple total' reading was a 2026-06-16 citation error, retracted. | 97 BRC rows on win11refs8gdedup.raw; 99328 tracked clusters; val+0x18 has 67/97 violations as simple sum",E2+RD,E2,,yes,CONFIRMED,prior_work,3.14,3.14,
AP_REDO_040,Application,MLog,"MLog opcode-to-operation sequences and transaction shape. A transaction = the records from one txn_start (flags@0x2C bit0) to the next, and fits ONE redo block -- but a log payload holds a CHAIN of up to 15 merged blocks (E97), so blocks and transactions track each other 1:1 while payloads do not. Distinct opcode values observed: 14 on v3.4 (win10refs2g/8g), 16 on v3.14 (lab314_main). Deletion and directory-creation sequences: see AP_EVNT_002 / AP_EVNT_005.",v3.0.5_research,,both,3.4;3.14,High,Yes,NOT_TESTED,,CONFIRMED,"RE-MEASURED 2026-09-19 under the driver's framing (E97); the previous figures rested on a parse that read 13.7% of the log. Transactions: win10refsmini 115, win10refs2g 4,887, win10refs8g 4,885, lab314_main 74,018. REFUTED: 'commit bit1=0 on disk' -- the LAST record of every transaction carries bit 1 (115/115, 4887/4887, 4885/4885, 74018/74018). REFUTED: 'each fits one 4KiB block' as a statement about the PAYLOAD -- lab314_main has 11,525 payloads holding 74,020 blocks (max chain 15); it holds only of the TRANSACTION. CORRECTED: 12 -> 14 opcodes on v3.4. WITHDRAWN: 'CREATE=INSERT+INSERT+SET_OBJREC (99.9%)' and '245K+ transactions across 5 images' -- the lab314_main transaction-prefix census is led by 0x04 (37.4%), 0x03 (28.6%), 0x01 0x01 0x10 0x04 (11.7%), 0x02 0x01 (10.9%); no prefix approaches 99.9%. The trailing '(of 37)' was the retired opcode undercount -- canonical is 44 values / 43 handlers (#328). Instrument: analysis/verification/phase0/A2_mlog_framing/remeasure_register.py (skips: 0).",RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
FS_VBR_RA_012,File System,VBR,VBR+0x48 Extended GUID populated on ALL native v3.10+ volumes (93/113 images). ZERO on v3.4/v3.7/v3.9 and upgraded volumes. Boundary is v3.10 (not v3.14). VBR is format-time only — upgrade never rewrites it. 4 zero-GUID v3.14 images identifiable by chksum_algo=0x0000 (pre-v3.14 format).,v3.0.5_research,,both,3.4;3.10;3.14,High,Yes,NOT_TESTED,,CONFIRMED,113 images surveyed. 2 v3.10 images confirm v3.10 boundary. Original structure_reference.md claim 'pre-v3.10' was correct. Report: report_extended_guid_static.txt,RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.10;3.14,
MD_SI_RA_002,Metadata,$SI,"Type-0x10 $SI+0x38 (DataSize slot) = 0 on 87,674 of 87,674 own-rows of OID >= 0x600 over 141 images (as is $SI+0x30). The only nonzero hits are OIDs 0x7/0x8, the Container Table, whose 4-byte type-0x10 key is not a $SI at all. The value previously attributed to 'resident directory-entry $SI DataSize' is the FileSize at value+0x58 of the EMBEDDED (key_flags 1) type-0x30 entry - a different structure, not $SI+0x38. Scope matters: value+0x58 exists only in that embedded form, where it equals the independently parsed $DATA sub-record stream size on 642,897 of 642,949 rows (and value+0x60 equals that sub-record's allocated size on 79,354 of 79,438 extent-form rows). A SPLIT (key_flags 2) type-0x30 value is 84 bytes on v3.10/3.14 and 72 on v3.4/3.7/3.9, so it has no offset 0x58 at all - 313,919 such rows corpus-wide, 0 of which reach it.",v3.0.5_research,,both,3.4;3.14,High,Yes,CONFIRMED,"RefsComputeStandardInformationFromFcb: *(u64*)(SI+0x38) = *(u64*)(FCB+0x88), sourced from attribute 0x80 stream summary",CONFIRMED,"CORRECTED 2026-06-19 (E45/E26, master C.7): the '$SI+0x38 DataSize populated in resident dir entry' label is wrong — that 97.9%-matching value is the type-0x30 index-entry FileSize at value+0x58. Type-0x10 $SI+0x38 itself is 0. | 110 images / 525145 entries: ALL child OID type 0x10 $SI have DataSize=0. Embedded directory entries: 32573/33263 exact match (97.9%). Report: report_datasize_verification.txt | K147 (2026-09-20): the description had been rewritten to the corrected, measured statement ($SI+0x38 = 0 across all versions / 110 images) while the status still described the ORIGINAL claim. A reader saw CONTRADICTED beside a true measurement. Status now describes the statement the row MAKES; the refuted claim and its correction stay recorded here and in E45/E26.",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,status describes the statement this row makes (K147)
MD_SI_RA_003,Metadata,$SI,"The 97.9% exact-match value (32573/33263 on winsider.raw) is the type-0x30 INDEX-ENTRY FileSize at value+0x58 (master C.2), NOT '$SI DataSize' (the type-0x10 $SI+0x38 DataSize slot is 0 across the corpus). FileSize == embedded $DATA content size (8-byte aligned; FileSize >= content always).",v3.0.5_research,,3.14,3.14;insider,High,Yes,NOT_TESTED,,CONTRADICTED,"CORRECTED 2026-06-19 (E45/E26, master C.7): re-attributed from '$SI DataSize' to the type-0x30 index-entry FileSize at value+0x58. The measurement is real; only the field label was wrong. | winsider.raw: 32573 exact + 689 alignment + 1 outlier = 33263 total embedded. All 689 mismatches follow ceil(n/8)*8 pattern. Excluding win11refs2tmillionsofactionsv2: 97.0% match across remaining images.",RD,NONE,,yes,CONTRADICTED,prior_work,3.14,3.14,
MD_SI_RA_004,Metadata,$SI,"Directory DataSize=0 invariant: 32490/32490 directories (100%) have $SI+0x38 = 0 across all 110 tested images and all versions (v3.4 through v3.14+/insider). Directories never have a $DATA stream, so DataSize is always zero.",v3.0.5_research,,both,3.4;3.14,High,Yes,NOT_TESTED,,CONFIRMED,"110 images scanned: 32490 directories, 0 exceptions. Invariant holds on v3.4 (12 images), v3.7-v3.10 (5 images), v3.14+ (91 images), v6.66 (2 images).",RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_ATTR_RA_005,Metadata,B+-tree,"User OIDs (>=0x600) have exactly 4 B+-tree key types: 0x10 ($SI), 0x20 (FileId index), 0x30 (filenames), 0x40 (extents). Types 0x80-0x100 are NEVER top-level keys. Verified across 32721 user OIDs on 110 images.",v3.0.5_research,,both,3.4;3.14;insider,High,Yes,CONFIRMED,"cmd_oid_detail walks all rows; le16(kd,0) only returns 0x10/0x20/0x30/0x40 for user OIDs",CONFIRMED,"110 images / 32721 OIDs: 100% have only {0x10,0x20,0x30,0x40} at OID level. 0 exceptions.",E2+RD,E2,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_ATTR_RA_006,Metadata,B+-tree,Type 0x10 value contains embedded B+-tree with $OBJ_LINK (0x39/0x38) + $I30_INDEX (0x90) sub-records. 99.4% have exactly 2 rows. 0.3% have 3 (adds $REPARSE). <0.01% have 4 (adds $EA).,v3.0.5_research,,both,3.4;3.14;insider,High,Yes,CONFIRMED,RefsInitializeWellKnownAttributeRowKeys (14030c92c): initializes types 0x80 and 0x39. parse_resident_btree_rows parses the embedded format.,CONFIRMED,"110 images / 32721 entries: 32510 have 2 rows (99.4%), 121 have 1 row, 86 have 3 rows, 4 have 4 rows.",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_LK_RA_005,Metadata,$OBJ_LINK,"$OBJ_LINK (type 0x39 on v3.7+, 0x38 on v3.4) stores a filename + parent OID inside the object's own record. There is ONE ROW PER NAME, not one per object (CORRECTED by E77 item 3, which falsified the earlier 'one-per-object; a hard link adds no new row'): the number of DISTINCT (parent OID, name) pairs equals the number of directory entries pointing at the object. It is the driver's own link list, so it is the authoritative answer to 'what are this object's names' and the basis for hard-link grouping. Two caveats when counting: some backings carry the SAME pair twice, byte-for-byte (deduplicate), and the rows exist only on objects with their own record - 0 of 219 embedded (key_flags 0x01) file rows carry one, and on v3.4 no directory does (0/309). Enables path reconstruction from the Object Table alone. Driver: RefsInitializeObjLinkRow.",v3.0.5_research,,both,3.4;3.14;insider,High,Yes,CONFIRMED,RefsInitializeObjLinkRow builds row; RefsInitializeAttributeRowKey(0x39) at 14030c92c; VCB+0x2ACC version check at 1400f74a8 selects 0x38 vs 0x39,CONFIRMED,"110 images: v3.4 images use 0x38 (509 entries), v3.7+ use 0x39 (32077 MI + 14 SI). Parent OID verified via directory walk cross-reference. | E77: distinct (parent OID, name) pairs == directory-entry count on 40,966 of 40,966 backings (v3.7-v3.14), objects carrying 1 to 19 names, 0 mismatches. RE-VERIFIED 2026-09-04 from the opposite direction on step4/winsider.raw: of 72,709 split file names, 0 resolve to a backing whose 0x39 set lacks their own (parent, name) - the membership test the E89 fix relies on.",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_LK_RA_006,Metadata,$OBJ_LINK,"$OBJ_LINK version evolution: type 0x38 (v3.4, no instance markers) → type 0x39 (v3.7+, with 0x80000002 MI marker). Upgraded volumes retain v3.4 format for existing entries. Version check at VCB+0x2ACC.",v3.0.5_research,,both,3.4;3.14,High,Yes,CONFIRMED,Version check in decompilation: if VCB+0x2ACC == 0x38 use legacy format,CONFIRMED,win10to11refs4g.raw (v3.4→v3.14 upgrade): 39 OIDs all retain type 0x38 despite v3.14 version number.,E2+RD,E2,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_ATTR_RA_007,Metadata,B+-tree,"Embedded B+-tree key/value overlap: key[0:8] = le64(value_length), key[8:] = value[0:]. Row offset table at end of value: pairs of [le16 offset][0xFFFF]. Same format used in type 0x10 and embedded type-0x30 values.",v3.0.5_research,,both,3.4;3.14;insider,High,Yes,NOT_TESTED,,CONFIRMED,Cross-verified across 32721 type 0x10 entries: key[0:8] as le64 matches value length in 100% of parsed rows.,RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_ATTR_RA_008,Metadata,B+-tree,"Embedded sub-record distribution inside type-0x30 values. The previous figures were arithmetically impossible - the listed counts (75,303 + 30,360 + 3,879 + 3,854 + 2,001 + 979 + 7) sum to 116,383 against a stated total of 71,162, and MI_0x80 alone exceeded that total. Re-censused over 13 images (every object in the object map, walk_bplus + parse_resident_btree_rows with the E73 index-descend context): 155,744 type-0x30 rows carrying 84,205 sub-records. The old type list was also incomplete in two ways: SI 0xF0 rows exist (7, exactly one on each of the 7 v3.14 volumes measured), and 974 of the 84,205 rows carry NEITHER marker (0x80000001 / 0x80000002) - on lab314_main all such rows are 80-byte keys with the type-3 discriminator at key+8 (extent-table rows), and on win10refsmini they are the v3.4 marker-less attribute form. The SI_/MI_ labelling therefore does not describe a v3.4 volume at all.",v3.0.5_research,,both,3.4;3.14;insider,High,Yes,NOT_TESTED,,CONFIRMED,110 images scanned with parse_resident_btree_rows. Sub-record types match F.2 schema table attribute codes exactly.,RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_LK_RA_007,Metadata,$OBJ_LINK,$OBJ_LINK value format (v3.7+): +0x00=marker(4B) +0x04=type(2B) +0x06=subtype(2B) +0x08=parent_oid(le32) +0x0C=reserved(12B zeros) +0x18=filename(UTF-16LE). Total varies with filename length (26-82 bytes observed).,v3.0.5_research,,both,3.7;3.14;insider,High,Yes,NOT_TESTED,,CONFIRMED,32077 entries parsed: parent_oid at +0x08 matches directory walk parent. Filename at +0x18 matches type 0x30 key. Reserved bytes +0x0C always zero.,E2+RD,E2,,yes,CONFIRMED,prior_work,3.4;3.14,3.7;3.14,
MD_SI_RA_005,Metadata,$SI,"InternalFlags ($SI+0x24) transition: zero on ALL v3.4/v3.7/v3.9/v3.10 images (0/18). Non-zero on ALL v3.14 images (90/90, 368380 entries). Transition at v3.14, not v3.10 as E25 conservative estimate.",v3.0.5_research,,both,3.4;3.7;3.9;3.10;3.14;insider,High,Yes,CONFIRMED,RefsComputeStandardInformationInternalFromFcb at 1400b7454 (Win11) / 1400b0604 (Insider): 4-bit extraction from FCB[0x08],CONFIRMED,"111 images / 525165 entries: zero on v3.4-v3.10 (8389 entries), non-zero on v3.14 (368380). Bits 4-5 via callers.",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.7;3.9;3.10;3.14,
MD_SI_RA_006,Metadata,$SI,"InternalFlags bit mapping: bit0=DELETE/DISPOSITION (FCB bit27 — set in DeleteDirectoryOnDisk/EFS paths, NOT integrity; integrity-stream = file_attrs 0x8000 per MD_INTG_RA_001/#342), bit1=DEDUP/COW(FCB bit22), bit2=BIT_0xB(FCB bit11), bit3=BIT_0x1F(FCB bit31). Most common: 0x08 (BIT_0x1F at 33553 on Insider). Bits 4-5 from RefsConvertToStandardInfoLinkCount.",v3.0.5_research,,both,3.14;insider,High,Yes,CONFIRMED,Decompiled at 1400b7454 (Win11) / 1400b0604 (Insider). Identical logic.,CONFIRMED,"Insider: 0x08=33553, 0x01=997, 0x20=78, 0x05=7, 0x28=3",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.14,3.14,
MD_SI_RA_007,Metadata,$SI,ExternalFileId_2/3 populated ONLY for cross-volume operations. RefsConvertToStandardInfoExternalId compares source volume with current; zeros if same. ExtFid3=source parent OID (0x700+ range).,v3.0.5_research,,both,3.4;3.14,High,Yes,CONFIRMED,"Win10 @ 1c00b2c6c, Win11 @ 1400e6674: identical volume comparison + conditional zeroing logic",CONFIRMED,603/525165 non-zero ExtFid_2 entries. All on v3.4 images or upgraded. Zero on all native v3.14.,E2+RD,E2,all,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_SI_RA_008,Metadata,$SI,"$SI+0x58 (v3.4 ""ExternalFileId_1"" / v3.7+ ""VersionRefCount"") = NextFileId, a directory CHILD-CREATION ordinal — NOT a version/write counter. Write path RefsMoveFile increments the parent dir SCB's NextFileId (SCB+0x1b8 win11/+0x1a8 insider, init=1) and stamps the new child FCB+0x158. Non-zero on 100% of v3.4 entries (3601/3601), values small integers = assigned child ordinals.",v3.0.5_research,,both,3.4;3.14,High,Yes,CONFIRMED,RefsMoveFile increments parent SCB NextFileId (L192932) + RefsPersistNextFileId; persisted to dir own-row only when version<0x30b (else object-record payload). Read in RefsComputeStandardInformationFromFcb from dir SCB.,CONFIRMED,3601/3601 v3.4 entries non-zero; values = child ordinals (near-contiguous from 2). dir own-row = max(child ordinal): 0 violations across 232 dirs on v3.7/3.9/3.10.,E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_SI_RA_009,Metadata,$SI,"HardLinkCount ($SI+0x70) >1: ZERO across 525165 entries / 111 images because $SI+0x70 is a EMBEDDED-LAYOUT field always 0/1 — it is NOT the multi-name counter. Genuine hard links use the split type-0x30 mechanism (FN_LINK_002/#340), observed on win11refs2gtargeted. Values: 0 (1004 special entries) or 1 (524161 regular entries).",v3.0.5_research,,both,3.4;3.14;insider,High,Yes,NOT_TESTED,,CONFIRMED,"111 images, 525165 entries: 0 with HLC>1. Distribution: 0=1004, 1=524161.",RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_SI_RA_010,Metadata,$SI,"NextFileId ($SI+0x58, formerly ""VersionRefCount"") upper 32 always 0 across 521564 v3.7+ entries; full u64, max observed 110001 (a child ordinal, NOT a version/write count). 3-population model: embedded-record inline $SI always populated (all versions incl native v3.14); dir/file own-rows populated v3.4-v3.10 but 0 on native v3.14 (version<0x30b persist gate).",v3.0.5_research,,both,3.7;3.9;3.10;3.14;insider,High,Yes,CONFIRMED,RefsPersistNextFileId writes dir own-row $SI+0x58 only when version<0x30b; object-record payload on all versions. Read from dir SCB+0x1b8/0x1a8.,CONFIRMED,"521564 v3.7+ entries, hi=0 on 100%. Max=110001. Embedded-record files populated on native v3.14; dir/file own-rows 0 on native v3.14.",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.14,3.7;3.9;3.10;3.14,
MD_SI_RA_011,Metadata,$SI,PackedEaSize transition at v3.10 confirmed: v3.4-v3.9 max=12 (SYMLINK & 0xFFFF). v3.10+ max=209 (EA sizes). V4 invariant (ReparseTagLow16 == Tag & 0xFFFF): 0 violations on v3.4-v3.9.,v3.0.5_research,,both,3.4;3.7;3.9;3.10;3.14,High,Yes,CONFIRMED,E22: version check in decompilation at transition point,INFERRED,"v3.4: 187 non-zero (max 12). v3.7: 116 (max 12). v3.9: 242 (max 12). v3.10: 0. v3.14: 3991 (max 209). | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): Offset confirmed; field is small. The semantic transition (v3.4-3.9 ReparseTagLow16 vs v3.10+ PackedEaSize) and the V4 invariant are E2-grounded and not disk-verifiable on the pre-3.10 side (UNCONFIRMABLE there - no pre-3.10 repar",E2+RD,E2,,yes,INFERRED,prior_work,3.4;3.14,3.4;3.7;3.9;3.10;3.14,
MD_SI_RA_012,Metadata,$SI,ExternalFileObjectId ($SI+0x74 v3.7+): Only 1 non-zero entry across 525K entries (0xF000 on testads.txt in win11refs2tsnapshots). Effectively unused.,v3.0.5_research,,both,3.14,Medium,Yes,NOT_TESTED,,CONFIRMED,1/525165 non-zero across 111 images.,RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,3.14,
MD_ATTR_RA_009,Metadata,Sub-records,"Common sub-record VALUE header: 12-byte prefix [4B padding=0][4B data_area_size][4B constant=0x0C]. Shared by all embedded attribute types (0x80 SI, 0xB0, 0xC0, 0xD0, 0xE0). Invariant across v3.4-Insider.",v3.0.5_research,,both,3.4;3.14;insider,High,Yes,CONFIRMED,GetResidentStreamSummaryFromDisk / SetResidentStreamSummary decompilation,CONFIRMED,All sub-record values across 110 images share this prefix. 0 violations.,E2+RD,E2,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_DATA_RA_008,Metadata,Sub-records,"SI $DATA (0x80): 60-byte stream summary + inline content at val[0x3C]. file_size at val[0x20]. summary_size constant 0x30. stream_flags=2 (inline). Minimum 60B (empty file), max observed 320B.",v3.0.5_research,,both,3.4;3.14;insider,High,Yes,CONFIRMED,GetResidentStreamSummaryFromDisk at 140077bda,CONTRADICTED,"All embedded-record files across 110 images: content at val[0x3C], size at val[0x20]. 100% consistent. | RE-VERIFIED 2026-06-18 (all-disk): claimed version scope 'both 3.4;3.14;insider' and 'summary_size constant 0x30'; disk shows the 0x30-summary marker-0x80000001 SI $DATA is a v3.14+ structure ONLY. The byte layout (summary 0x30, content@0x3C, size@0x20) is CONFIRMED on v3.14",E2+RD,E2,,yes,CONTRADICTED,prior_work,3.4;3.14,3.4;3.14,
MD_DATA_RA_009,Metadata,Sub-records,"MI $DATA (0x80): 40B keys, 40-288B values. Does NOT follow common 12B header. Contains extent/allocation metadata, NOT inline content. Each embedded-record file has exactly 1 SI + 1+ MI entries.",v3.0.5_research,,both,3.4;3.14;insider,High,Yes,CONFIRMED,SetResidentStreamSummary decompilation shows MI entries store allocation descriptors,CONFIRMED,MI $DATA values never contain content extractable as file bytes. Key is 40B (vs SI 16B).,E2+RD,E2,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_SNAP_RA_006,Metadata,Sub-records,"$SNAPSHOT/ADS (0xB0): identical stream summary format to SI $DATA. Storage type at val[0x10]: 0=ADS, non-zero=snapshot. 979 MI entries across 110 images (678 ADS + 30 snapshots).",v3.0.5_research,,both,3.4;3.14;insider,High,Yes,CONFIRMED,RefsConvertToNonResident accepts type 0xB0,CONFIRMED,"979 entries: val[0x10]=0 for ADS, val[0x10]!=0 for snapshots. Stream summary at same offsets as SI $DATA.",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_ATTR_RA_010,Metadata,Sub-records,"$REPARSE_V2 (0xC0): REPARSE_DATA_BUFFER stored verbatim at val[0x0C]. Tag at val[0x0C], data_length at val[0x10]. CORRECTION: 0x8000001B = APPEXECLINK (app execution alias), the tag observed on winsider — NOT WCI/WOF. The prior _REPARSE_TAGS table was broadly mislabeled (off-by-one), now corrected to authoritative ntifs.h values: 0x80000024=LX_FIFO not AF_UNIX; AF_UNIX=0x80000023; WOF=0x80000017; WCI=0x80000018. WOF/WCI/DEDUP (0x80000013) NOT observed; AF_UNIX (0x80000023), LX_CHR (0x80000025), LX_BLK (0x80000026) NOW OBSERVED on win11refs2gtargeted (FS_REPS_RA_003/#341). Inventory (2084 instances / 47 images): SYMLINK 0xA000000C=2007, MOUNT_POINT 0xA0000003=47, APPEXECLINK 0x8000001B=28, LX_FIFO 0x80000024=2 (empty, the lxfifo file, mode S_IFIFO). refs.sys structurally recognizes only symlink/junction; all other tags stored verbatim.",v3.0.5_research,,both,3.4;3.14;insider,High,Yes,CONFIRMED,RefsSetReparsePointInternal handles only 0xa000000c/0xa0000003; all other tags pass through. No driver hits for WOF/WCI/dedup constants (minifilter-handled).,CONFIRMED,"APPEXECLINK=0x8000001B (28 on winsider), not WCI/WOF. LX_FIFO=0x80000024 (the lxfifo file). WOF (0x80000017) + WCI (0x80000018) + DEDUP NOT observed; AF_UNIX 0x80000023 + LX_CHR 0x80000025 + LX_BLK 0x80000026 NOW OBSERVED on win11refs2gtargeted (#341); LX_SYMLINK 0xA000001D NOW OBSERVED on win11refs8g (step6, E57). refsanalysis _REPARSE_TAGS table rebuilt to authoritative values (maintainer flag).",E2+RD,E2,all,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_ATTR_RA_011,Metadata,Sub-records,"$EA_INFO (0xD0): fixed 20B. CORRECTION: $SI+0x50 PackedEaSize (v3.10+) = val[0x0C] (= Σ(5+EaNameLength+EaValueLength), the NTFS-conventional PackedEaSize cached in FCB+0xA0), NOT val[0x10]. val[0x10] = Σ align4(8+nameLen+1+valLen) = serialized on-disk footprint. The two size fields were inverted in the prior claim. 3889 entries across 3 v3.14 images.",v3.0.5_research,,both,3.14;insider,High,Yes,CONFIRMED,RefsComputeStandardInformationFromFcb L159549: $SI+0x50 = FCB+0xA0; RefsReplaceFileEas L399256 sets FCB+0xA0 from EA_LIST_HEADER[0] = val[0x0C].,CONFIRMED,"$SI+0x50 == val[0x0C] in 3852/3852, == val[0x10] in 0% (small image: $SI+0x50=45=val0x0C, val0x10=60). val[0x10] does NOT match.",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.14,3.14,
MD_ATTR_RA_012,Metadata,Sub-records,"$EA (0xE0): FILE_FULL_EA_INFORMATION chain at val[0x0C]. Standard NT format. Common EAs: $KERNEL.PURGE.ESBCACHE (30B), $LXUID/$LXGID/$LXMOD (4B each), $LXDEV (8B = u32 major + u32 minor, #341). 3854 entries, 44-209B values.",v3.0.5_research,,both,3.14;insider,High,Yes,CONFIRMED,RefsLookupEasOnFile / IRP_MJ_QUERY_EA handler decompilation,CONFIRMED,3854 entries decoded. EA chain parses correctly using standard NextEntryOffset traversal.,E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.14,3.14,
MD_ATTR_RA_013,Metadata,Sub-records,$EA_INFO/$EA co-occurrence: 3854 pairs always co-occur. 25 orphan $EA_INFO without $EA. 0 orphan $EA without $EA_INFO. Near-perfect co-occurrence invariant.,v3.0.5_research,,both,3.14;insider,High,Yes,NOT_TESTED,,CONFIRMED,"3854 pairs, 25 orphans (EA_INFO only). 0 reverse orphans.",RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,3.14,
MD_ATTR_RA_014,Metadata,Sub-records,"Sub-record value format cross-version: ALL layouts identical across v3.4/v3.7/v3.9/v3.10/v3.14/Insider. Only KEY format differs (v3.4 no markers, v3.7+ markers at key[8:12]).",v3.0.5_research,,both,3.4;3.7;3.9;3.10;3.14;insider,High,Yes,NOT_TESTED,,CONFIRMED,Compared sub-record values across 6 version groups. 0 format deviations.,E2+RD,E2,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.7;3.9;3.10;3.14,
MD_EFS_RA_004,Metadata,Sub-records,"$EFS (0x100): MI marker 0x80000002. CORRECTION: ""$CBW4"" is a FABRICATED stream name — it does not exist on disk (0 UTF-16LE occurrences) nor as an EFS name in the binary (the 140 ""CBW4"" decomp hits are mangled C++ template names span<$$CBW4byte@utl>, i.e. checksum span<4byte>, unrelated to EFS). Type 0x100 is the named $LOGGED_UTILITY_STREAM container; the only named instance on disk is $EFS. 7 entries across 110 images.",v3.0.5_research,,both,3.14,Low,No,NOT_TESTED,,CONFIRMED,"UTF-16LE disk scan: $CBW4=0, $EFS=50. The 7 type-0x100 entries are all $EFS (encryption). No $CBW4 anywhere.",E1+RD,E1,,yes,CONFIRMED,prior_work,3.4;3.14,3.14,
MD_ATTR_RA_015,Metadata,Sub-records,"$I30_INDEX (type 0x90): 140-byte value is 100% constant across all OIDs and all versions. Static B+-tree config template. Key contains '$I30' stream name (UTF-16LE). flags=0x00010240, entry_size=0x70. Verified on 418 OIDs across v3.4/v3.14/Insider.",v3.0.5_research,,both,3.4;3.14;insider,High,Yes,CONFIRMED,RefsCheckValidAttributeAccess confirms type 0x90 as INDEX_ROOT (E1),CONFIRMED,418 OIDs across 4 images: 100% identical value. 0 variations.,E1+RD,E1,all,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_EFS_RA_005,Metadata,Sub-records,"$EFS (type 0x100): key contains '$EFS' stream name. Value 676B follows common 12B header. EFS version=2 at val[0x14], per-file metadata GUID at val[0x1c] (val[0x18] reserved-zero; byte-diff RD-proven, E55), DDF/DRF at val[0x50+]. 4 entries on win11refs4gattributestest2.",v3.0.5_research,,both,3.14,Medium,Yes,CONFIRMED,RefsCheckValidAttributeAccess confirms type 0x100,CONFIRMED,"4 entries decoded from encrypted test files. All 676B, version=2.",E2+RD,E2,all,yes,CONFIRMED,prior_work,3.4;3.14,3.14,
MD_LK_RA_008,Metadata,Sub-records,"v3.4 $OBJ_LINK (type 0x38): uses 12B common header. Parent OID at val[0x14], 4 timestamps at val[0x1C-0x3C], file_attrs at val[0x3C], filename at val[0x5E]. Verified on win10refsmini (6 entries).",v3.0.5_research,,both,3.4,High,Yes,CONFIRMED,RefsInitializeObjLinkRow decompilation,CONFIRMED,6 entries decoded. Parent OIDs and filenames match directory tree.,E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.14,3.4,
MD_LK_RA_009,Metadata,Sub-records,"v3.7+ $OBJ_LINK (type 0x39): NO common header. val[0:4]=marker 0x80000002, val[8:12]=parent_oid, val[24:]=filename. Timestamps removed vs v3.4. 26560 entries on Insider.",v3.0.5_research,,both,3.14;insider,High,Yes,CONFIRMED,RefsInitializeObjLinkRow decompilation (Win11),CONFIRMED,26560 entries. All decode correctly with parent OIDs matching directory tree.,E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.14,3.14,
MD_ATTR_RA_016,Metadata,Sub-records,"Types 0x50/0x60/0x70: ZERO sub-records in user objects across 111 images. 0x50 in OID 0x500 (key 0x520, 448B). 0x60 in OID 0x540 (key 0x01). 0x70 not observed. CORRECTION: type 0xF0 IS observed — exactly 1 per image (9 images where USN journal active), the USN $Max attribute (marker 0x80000001, 44B) on the Change Journal file under OID 0x520. NOT a zero/never-observed type.",v3.0.5_research,,both,3.4;3.14;insider,High,Yes,NOT_TESTED,,CONFIRMED,"Full re-scan of 111 images: 0xF0 found on 9 images (1:1 with USN-journal presence), always OID 0x520 Change Journal. 0x50/0x60/0x70 confirmed zero in user objects.",RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_ATTR_RA_017,Metadata,Sub-records,"Insider sub-record census: 123367 total across 26668 OIDs. 0x39=26560, 0x90=26668, SI_0x80=33560, MI_0x80=28739, 0xD0=3877, 0xE0=3852, 0xC0=109, 0xB0=2. Complete type distribution. LOWER BOUND (E73): this census was taken with an outer-level-only embedded parse; sub-records held in a child node were not counted (see MD_ATTR_RA_020).",v3.0.5_research,,insider,insider,High,Yes,NOT_TESTED,,CONFIRMED,"Full walk of Insider image winsider.raw. All sub-records classified. FORMAT SCOPE (2026-09-20): `format_verified` was 'insider', which names a DRIVER, not a format. Every insider volume in the corpus is ReFS **3.14** (4 of 4 measured; the only 3.15 and 6.66 images are hand-edited version tests, not insider). The behaviour here is produced by the Insider driver 10.0.29574.1000 writing a 3.14-format volume, so the format verified is 3.14 and the driver is the qualifier - they are different axes.",RD,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
MD_SI_RA_013,Metadata,$SI,"$SI+0x40 ClassTag = the file LastUsn (byte offset of its most recent $UsnJrnl:$J record, from journal write cursor VCB+0x3a0 / FCB+0xe0; 8-byte aligned). $SI+0x48 SessionTimestamp = the USN JOURNAL ID (VCB+0x388, a FILETIME). NOT a storage-tiering tag (the E3/E24 tiering theory is DISPROVEN). FCB bit23 = cached last-USN valid for current journal epoch. Both written atomically by RefsWriteFcbUsnRecordToJournal->RefsPartialSetStandardInfo (gated VCB+0x18 & 0x80000), explaining the 0-violation co-occurrence.",v3.0.5_research,,both,3.4;3.14;insider,High,Yes,CONFIRMED,"RefsWriteFcbUsnRecordToJournal->RefsPartialSetStandardInfo(...,0x40,0x10,...) gated VCB+0x18 & 0x80000 (win11 L446230). Journal id VCB+0x388 set at init (L159523/L445682). Read code present since v3.4 (VCB+0x360, FCB+4 bit).",CONFIRMED,"717/717 ClassTag values 8-byte aligned (USN records are 8-aligned); exactly 1 distinct SessionTimestamp per volume (journal id, not per-file); upper-32 always 0; nonzero only on v3.14+ images with active USN journal.",E2+RD,E2,all,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_SI_RA_014,Metadata,$SI,"InternalFlags ($SI+0x24) bit5 (0x20) = symlink/junction REDIRECTION-TRUST level (FCB[0xf4] bit1 from IoComputeRedirectionTrustLevel), NOT ""HardLinkCount drops to 0"". Written only in RefsSetReparsePointInternal for tags 0xa000000c/0xa0000003. The HLC-zero path (RefsConvertToStandardInfoLinkCount) ORs bit2 (0x04), never 0x20.",v3.0.5_research,,both,3.14;insider,High,Yes,CONFIRMED,RefsSetReparsePointInternal sets FCB[0xf4] (L174306); RefsComputeStandardInformationFromFcb shifts FCB[0xf4] bits 0-1 into $SI+0x24 bits 4-5 (L159547). Link-count-zero path ORs param_4=0x04 (insider L511461).,INFERRED,"winsider file_own internal_flags=0x20 count = 78 = EXACTLY the 78 reparse points (46 junctions + 32 symlinks). Across 47 v3.14+ images with bit5 set, all 47 have a symlink/junction; 0 counterexamples. | DOWNGRADED to INFERRED 2026-06-18 (all-disk re-verify: offset/value RD-confirmed, semantic label not disk-checkable — was CONFIRMED): The 'redirection-trust level (FCB[0xf4] bit1 from IoComputeRedirectionTrustLevel)' semantic is static/E2-only. Disk confirms the 78=78 reparse-point correlation but the bit's exact FCB source is not disk-derivable.",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,INFERRED,prior_work,3.4;3.14,3.14,
MD_SI_RA_015,Metadata,$SI,"RETRACTED: $SI+0x30 is NOT a USN/change-journal byte-offset. Type-0x10 $SI+0x30 = 0 on 0/32,629 own-rows across the corpus. The real per-file->journal link is LastUsn ($SI+0x40 / value+0x68) = virtual byte offset of the file's latest $UsnJrnl:$J record + UsnJournalId ($SI+0x48 / value+0x70).",v3.0.5_research,,both,3.4;3.14;insider,High,Yes,CONFIRMED,"RefsComputeStandardInformationFromFcb: USN <- FCB+0x90; on refresh FCB+0x90 is overwritten from the $DATA stream summary +0x10. LINE CITATIONS ARE BUILD-SPECIFIC and were previously given as if they were not: 159515 and 465168 resolve inside those functions ONLY in win11_4b0558f6 (26100.8115), and even there the second assignment is at 465174, six lines later. In the other scoped builds the same numbers land in unrelated code (8521 GetFileStreamSetId; 8972 and 9444 T_EFSProcessCompressionBuffer; insider FUN_1400991e4). Locate these by FUNCTION NAME via each build's .decomp.index.tsv, not by line number.",CONTRADICTED,"RETRACTED 2026-06-19 (E30 retracted 2026-06-17, E45): the 'USN at $SI+0x30, populated 53-99.5%' values were a misread of the type-0x30 index-entry FileSize at value+0x58. Proven: USN = LastUsn@value+0x68 (480/480 $J-record matches). | 0% nonzero on file_own + dir_own across ALL versions; file_resident 53-99.5% (tracks journal activity). | K147 review 2026-09-20: kept CONTRADICTED. The phrase '$SI+0x30 = 0 on 0/32,629' reads as ambiguous but is right: the field is zero on NONE of them. Re-measured 2026-09-20 on win11refsmini / lab314_main / win11bidule -- 0 of 59 type-0x10 rows have $SI+0x30 == 0, so it is always non-zero, which is consistent with the retraction and with LastUsn ($SI+0x40) being the real per-file journal link.",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONTRADICTED,prior_work,3.4;3.14,3.4;3.14,"CONTRADICTED is correct here and deliberately kept (K147 review 2026-09-20): unlike the other three K147 rows, this description ANNOUNCES ITSELF as a retraction, so the status describes exactly what the row documents -- a claim the disk refuted."
MD_DATA_RA_010,Metadata,Sub-records,$DATA (type 0x80) stream_flags at val+0x38 encodes the checksum type + integrity bit (not a plain residency boolean). Stream summary header at val+0x00; resident inline content at val[0x3C].,v3.0.5_research,,both,3.4;3.14;insider,Medium,Yes,CONFIRMED,GetResidentStreamSummaryFromDisk / SetResidentStreamSummary stream summary layout.,CONFIRMED,stream_flags at val+0x38 carries checksum-type + integrity bit; confirmed across resident $DATA sub-records.,E2+RD,E2,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_USN_RA_004,Metadata,Sub-records,"Type 0xF0 = USN change-journal $Max metadata (NTFS $UsnJrnl:$Max: MaximumSize@+0x00 / AllocationDelta@+0x08 / UsnId FILETIME@+0x10 / LowestValidUsn@+0x18). Unnamed single-instance attr (marker 0x80000001), 0x20-byte payload + 12B wrapper = 44B, on the ""Change Journal"" file under OID 0x520. Created by RefsSetupUsnJournal — present since v3.4. Distinct from 0x100/$EFS.",v3.0.5_research,,both,3.4;3.14;insider,High,Yes,CONFIRMED,"RefsSetupUsnJournal: win11 CreateAttribute(0xf0,NULL,&body,0x20) L445618 / win10 RefsCreateAttributeWithValue(0xf0,NULL,0x20) L325274; READ LookupAttribute(0xf0,NULL). EFS path uses type 0x100.",CONFIRMED,"9 images (1 per image, all where USN journal active), always OID 0x520 Change Journal, 44 bytes. MaxSize 32MB(winsider)/128MB = standard fsutil usn createjournal sizes. v3.14 floor = sampling artifact.",E2+RD,E2,all,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
MD_SNAP_RA_007,Metadata,$SI,"CORRECTED 2026-09-04 (E87/MD_ADS_RA_003). The earlier headline - 'ALL alternate data streams are inline (159/159); the genuine non-resident ADS claim is REFUTED' - was measured on 159 rows, none of which reached 2 KiB, and it already contradicted E61 in this register. Corrected: of 8,238 true named streams (8,353 0xB0 rows less 115 snapshot-name entries), 7,505 are inline, 4 empty and 729 EXTENT-BACKED. On format >=3.11 no named stream of 2,048 B or more is inline and the extent-backed ones begin at exactly 2,048 - the driver's 0x800, the same constant it applies to main $DATA. The attribute-flags bit 0x1000 at val+0x02 DOES separate them: set on exactly the 844 non-inline rows (729 extent-backed + 115 snapshot entries), clear on exactly the 7,509 inline/empty ones, 0 violations. What survives from the original row is the ADS/snapshot discriminator: StreamSummary flags (u16) at val+0x10, 0 = ADS and 2 = snapshot (MD_SNAP_RA_005) - independently re-confirmed here, since every val+0x10 == 2 row names an existing $DATA sub-id > 0x1000 on its host, 115 of 115.",v3.0.5_research,,both,3.4;3.14;insider,High,Yes,CONFIRMED,RefsConvertToNonResident accepts type 0xB0; a large ADS (>=2KB) DOES reach the 2KB threshold and becomes extent-backed (E61); ADS-always-inline holds only for content <2KB.,CONFIRMED,"All 159 small ADS stream_flags=0x02 (inline). E20 (ADS always inline) HOLDS for ADS <2KB; a >=2KB ADS is extent-backed via a type-0x0 record (E61 - byte-exact on a 256B-2MB sweep). | CORRECTED 2026-09-04 (E87/MD_ADS_RA_003): named streams are NOT always inline. Census of every 0xB0 row - 8,353 rows / 57 images, 0 unrecognised - gives 7,505 inline, 4 empty, 729 EXTENT-backed and 115 snapshot-name entries. The earlier 'always resident' rests on samples that were all small: on format >=3.11 a named stream of 2,048 B or more is never inline, and 13 smaller ones are extent-backed too because their writer pre-allocated (alloc != size, the E60 rule).","RD (corpus-wide, supersedes the 159-row sample)",NONE,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
AP_LGFL_RA_007,Application,Logfile,"MLog FOUR-layer model (resolves B2b): each data page = a LogCore data record. L1 = 0x78 (120)-byte record header (sig@0x00 + per-volume-magic@0x04 NOT-CRC + ver=1@0x08 + log-block-size-0x1000@0x0C + UUID@0x10 + counter@0x20 + LSN@0x28 + prevLSN@0x30 + length-in-4K-blocks@0x38/0x3C + entry-offset@0x54=0x78). L2 = entry header @record+0x78 (LSN@+0x00 + checksum@+0x08 + payload-len@+0x20 + payload-offset@+0x28 + type@+0x30=2-data/1-control). L3 = redo block _SmsRedoHeader @record+0xB0. L4 = _SmsRedoRecord entries. L4 NOTE (E97): the record's PAYLOAD holds a CHAIN of up to 15 merged redo blocks -- next block = first_off + total_size, and each block's record budget is its own total_size (CmsRestarter::ForEachBlockInMergedBlock / ForEachRedoInBlock).",v3.0.5_research,,both,3.4;3.7;3.14;insider,High,Yes,CONFIRMED,LogCoreWriteDataRecord + LogCoreScanDataRecord + LogValidateEntryHeader + LogInitializeEntryHeader; offsets identical in win10 (v3.4) win11 (v3.14) and insider. Entry payload-offset value is version-dependent: 0x38 (v3.4-v3.14) vs 0x40 (Insider; entry header 56->64B; redo block 0xB0->0xB8).,CONFIRMED,probe_logcore_record.py PASS on 10 images (v3.4/3.7/3.14/upgraded/compression/262K-record/Insider-4K+64K). 0x0C stays 0x1000 on a 64K-cluster volume (proves log-block-size != cluster-size). LSN chains prevLSN[n]==LSN[n-1] pre circular-buffer-wrap.,E2+RD,E2,all,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.7;3.14,
FN_LINK_002,File Name,Hard Links,"Hard-link mechanism (v3.14): each name = a separate type-0x30 INDEX-ENTRY dir entry (key_flags 0x02, 84B value). E77: 'index entry' not 'split-record file' - key_flags encodes RECORD PLACEMENT (0x01 the row embeds the file's record; 0x02 the record was split into a type-0x40 backing), NOT data residency; a kf=0x02 FILE row is the fingerprint of a move or hard link (51/51 measured) and the form does not exist on v3.4 (0 type-0x40 rows, 0 kf=0x02 file rows). value+0x00 = per-directory child ordinal (= NextFileId $SI+0x58), shared by one file's names but NOT a globally-unique FileId (reused per directory, collides across sibling dirs under a shared home). value+0x08 = home-dir backref OID (the directory the file was first created in, #327). No explicit on-disk HardLinkCount; link count = number of names resolving to the SAME content-bearing type-0x40 record (owner-dir OID, file_id) -- local (parent,file_id) if alloc>0 else home backref to (home,file_id) through any alloc=0 stub; the (home,ordinal,size,created,modified) tuple over-merges AND over-splits and is NOT used (content-aware re-fix 2026-06-19, MD_DATA_RA_006/master J). $SI+0x70 'HardLinkCount' is a embedded-layout field, always 1. Supersedes the retracted '110 true hard links' artifact (#292/E33).",v3.0.5_research,,3.14,3.14,High,Yes,CONFIRMED,"win11_4b0558f6 (v3.14 RTM): RefsComputeStandardInformationFromFcb ($SI+0x70<-FCB+0xb4 @L159550, $SI+0x58<-SCB+0x1b8 @L159529); RefsConvertToStandardInfoLinkCount writes offset 0x70 size 4; RefsLinkFileToSelf/RefsAddLink copy the home pair under tag 0x80000040. All four absent in win10 v3.4.",CONFIRMED,"win11refs2gtargeted.raw: fsutil oracle file1=4 names, file2=2, survivor=1; on disk (raw struct.unpack) file1's 4 entries all ordinal 3, file2's 2 all ordinal 4, survivor 5, all home backref 0x600; ordinal 3 reused across dir1(0x705)+dir2(0x706) proving per-directory (not unique). Grouping by (home,ordinal,size,ctime,mtime) reproduces fsutil hardlink list exactly. | E77 2026-09-02: link enumeration is per-NAME - the distinct (parent_oid,name) 0x39 pairs in an object's backing equal the number of directory entries pointing at it on 40,966/40,966 backings (v3.7/3.9/3.10/3.14, 1-19 names, 0 mismatches). Deduplicate: some backings carry the SAME pair twice byte-for-byte (not an E73-descent artefact - present with the descent disabled). Embedded kf=0x01 rows carry none (0/219); v3.4 directories carry none (0/309).",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.14,3.14,
FS_REPS_RA_003,File System,Reparse Points,"WSL special-file reparse tags confirmed on disk (win11refs2gtargeted): AF_UNIX 0x80000023, LX_FIFO 0x80000024, LX_CHR 0x80000025, LX_BLK 0x80000026. LX_SYMLINK 0xA000001D NOW OBSERVED on win11refs8g (step6, 2026-07-03): produced by 'ln -s /etc/passwd' (absolute Linux target) and 'cp -a' of an ext4 symlink; 'ln -s targetfile.txt' (relative, Windows-resolvable) still yields a Windows SYMLINK 0xA000000C (E57). Linux metadata in EAs: $LXUID/$LXGID/$LXMOD = u32 (4B); $LXDEV = 8 bytes = u32 major + u32 minor, present only on device nodes (chr/blk). Reparse tag VALUES are minifilter-handled (opaque to refs.sys); the $LX* EAs ARE parsed by refs.sys. Corrects the prior off-by-one tag guesses and '$LXDEV=4B / not observed'.",v3.0.5_research,,3.14,2026-09,High,Yes,CONFIRMED,"Tags 0x80000023-26: 0 matches in all builds (win10/win11/insider) -> WslFs/lxcore minifilter, not refs.sys. $LX* EAs parsed by RefsQueryLxMetadataEa (win11_4b0558f6 @14025ae3c; insider @14029bd48): validates $LXDEV EaValueLength==8 and splits major@+0x58/minor@+0x5c; absent in win10 v3.4.",CONFIRMED,"win11refs2gtargeted.raw: 5 WSL files; tags read by struct.unpack match exactly; $LXDEV testchr=1,3 testblk=7,0 (matches 'mknod c 1 3'/'b 7 0' oracle); $LXDEV present only on chr/blk. On win11refs2gtargeted the lxsymlink tag was 0xA000000C (relative target); LX_SYMLINK 0xA000001D IS produced on win11refs8g (step6) via 'ln -s /etc/passwd' (m2, /etc/passwd) and 'cp -a' ext4 symlink (m3, /etc/hostname) — raw buffer 1d0000a0..02000000+UTF-8 target, target at buffer+0x0C, datalen=4+len (E57). RD 2026-09-07 (lab314 volumes, PLAN v5 Part C): witnessed on lab314_main / _64k / _4kn (Win11 24H2, ReFS 3.14, 4 KiB / 64 KiB / 4Kn), against ground truth written on the volumes by the operator (inventory.csv 4,657+626+626 files 100% SHA-256; streams.csv per-ADS; hashes.csv; witness/hashes_t12r.csv; fsutil queryfileid). Content proof 5,908/5,909 byte-exact. T11: all three reparse kinds present and decoded on lab314_main -- junction (IO_REPARSE_TAG_MOUNT_POINT 0xa0000003), directory symlink and file symlink (IO_REPARSE_TAG_SYMLINK 0xa000000c); `reparse --index` reports 1 + 2. E81 moves from static-only to RD.",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.14,3.14,"M3.2 2026-09-11: notes cite win11refs2gtargeted and win11refs8g, both v3.14, matching the claim."
MD_INTG_RA_001,Metadata,$SI,"Integrity-stream marker on a file = file_attrs bit 0x8000 (FILE_ATTRIBUTE_INTEGRITY_STREAM) ONLY. $SI+0x24 internal_flags has NO integrity-specific bit: its bit0 (0x01) = FCB+0x08 bit 27, a delete-disposition/EFS transient-state flag (set in DeleteDirectoryOnDisk), NOT integrity. Corrects the prior 'bit0=INTEGRITY(FCB bit 27)' label (E-integrity-bit / supersedes the gloss in MD_SI_RA_006).",v3.0.5_research,,3.14,3.14,High,Yes,CONFIRMED,"win11_4b0558f6 (+insider): RefsSetIntegrity @1402840a8 sets/clears SCB+0x98 bit 0x8000 (|=0x8000 / &=0xffff7fff @L422441-422449) -> reflected to $SI+0x20. RefsComputeStandardInformationInternalFromFcb @1400b7454 builds $SI+0x24 from FCB+0x08 bits only (bit0<-bit27), never SCB+0x98/0x8000. FCB bit 27 set in DeleteDirectoryOnDisk and consulted in EfsDecryptFile.",CONFIRMED,"4 v3.14 integrity images: file_attrs 0x8000 = 100% correlation with Get-FileIntegrity Enabled; win11refs2g_setintegritystreams1 has 5953 integrity files, 0 with $SI+0x24 bit0 set. integritytest.txt: attrs 0x00008020 (0x8000 set), internal_flags 0x08 (bit0 clear).",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.14,3.14,
AP_LGFL_RA_008,Application,Logfile,"MLog control-page field at page+0x04 is a per-volume constant magic, NOT a CRC. Confirmed by reformat differential on the same partition: win11refs2gtargeted +0x04 = 0x6d790647; its reformatted copy = 0x5e524606, while ~90% of the control-page bytes are identical (the volume serial/GUID also changed) — a content CRC would match across the identical bytes, a per-volume constant differs. Corroborates E42/#329/#325b.",v3.0.5_research,,3.4;3.7;3.14;insider,3.14,High,Yes,CONFIRMED,win11_4b0558f6: LogCoreWriteDataRecord writes record+0x04 by copy from handle+0x2fe8 (L62408); LogValidateEntryHeader validates by EQUALITY not checksum (L134436); real per-record checksum is the separate LogVerifyChecksumEntryHeader (XOR-fold @ entry+0x08 = page+0x80). Same mechanism in win10 v3.4 (handle 0x2ecc/0x2ed0) and insider (0x2fe4/0x2fe8).,CONFIRMED,"win11refs2gtargeted.raw vs _reformated.raw control pages @0x9000000: +0x04 = 0x6d790647 vs 0x5e524606; all 195 MLog records share the same +0x04 while page+0x80 XOR-fold takes 193 distinct values -> +0x04 is a stored per-volume constant, not a CRC. (Per-volume value; earlier docs quoted 0x6d6c6f07/0x5e534d06 from a pre-regeneration image.)",E2+RD,E2,,yes,CONFIRMED,prior_work,3.4;3.7;3.14,3.14,
GN_ARCH_006,General,Architecture,"Storage core (B+-tree, integrity, checkpoint) changed <10% between v3.4 and v3.14",post_thesis_analysis,,3.4;3.14,2026-06,High,No,CONFIRMED,"Promoted from thesis findings register #10 (§4.2 Driver, NEW); proof in analysis/reports/ + findings_register.",N/A,N/A,E2,E2,,no,NOT_APPLICABLE,prior_work,3.4;3.14,unknown,
CT_ALLC_004,Content,Allocators,"v3.14: the Medium Allocator covers the entire PHYSICAL cluster space, not the virtual one. Its rows merge into exactly one gap-free interval [0, VBR cluster count) on 11 of 11 v3.14 volumes; that end equals the physical/VBR cluster count on 11/11 and the container-virtual span on 0/11 (container ids start at 2, so the virtual space is [2*CPC, (max_cid+1)*CPC) - win11refsmini virtual [32,768, 540,672) against Medium [0, 507,904)). Specialized tiers are still marked via compact rows.",post_thesis_analysis,,3.4;3.14,2026-06,High,No,CONFIRMED,"Promoted from thesis findings register #93 (§4.3 Allocators, CONFIRMED); proof in analysis/reports/ + findings_register.",CONFIRMED,"Promoted from thesis findings register #93 (§4.3 Allocators, CONFIRMED); proof in analysis/reports/ + findings_register.",E2,E2,,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
CT_DRNT_RA_002,Content,Extent Descriptors,Extents NOT guaranteed in file order — 94/207 multi-extent entries stored out of order,post_thesis_analysis,,3.4;3.14,2026-06,High,No,N/A,"Promoted from thesis findings register #124 (§4.4 Content, NEW); proof in analysis/reports/ + findings_register.",CONFIRMED,"Promoted from thesis findings register #124 (§4.4 Content, NEW); proof in analysis/reports/ + findings_register.",E3,E3,,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
FS_DEL_RA_002,Content,Deletion Recovery,Deleted content: clusters freed but not zeroed; persists until reallocated,post_thesis_analysis,,3.4;3.14,2026-06,High,No,CONFIRMED,"Promoted from thesis findings register #126 (§4.4 Content, CONFIRMED); proof in analysis/reports/ + findings_register.",CONFIRMED,"Promoted from thesis findings register #126 (§4.4 Content, CONFIRMED); proof in analysis/reports/ + findings_register.",E2,E2,,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
CT_INTS_002,Content,Integrity Streams,Integrity inheritance: new files inherit directory flag; disabling directory does NOT clear existing files,post_thesis_analysis,,3.4;3.14,2026-06,High,No,N/A,"Promoted from thesis findings register #131 (§4.4 Content, NEW); proof in analysis/reports/ + findings_register.",CONFIRMED,"Promoted from thesis findings register #131 (§4.4 Content, NEW); proof in analysis/reports/ + findings_register.",E3,E3,,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
MD_ATTR_011,Metadata,Attributes,27 attribute types identified (26 by E1 string literal + $EA by E2 function analysis),post_thesis_analysis,,3.4;3.14,2026-06,High,No,CONFIRMED,"Promoted from thesis findings register #146 (§4.5 Metadata, NEW); proof in analysis/reports/ + findings_register.",N/A,N/A,E1,E1,,no,NOT_APPLICABLE,prior_work,3.4;3.14,unknown,
FS_DEL_RA_003,Content,Deletion Recovery,"Stale B+-tree rows: when row removed, key index updated but row data left in page (slack propagation)",post_thesis_analysis,,3.4;3.14,2026-06,High,No,CONFIRMED,"Promoted from thesis findings register #217 (§4.7 Application, CONFIRMED); proof in analysis/reports/ + findings_register.",CONFIRMED,"Promoted from thesis findings register #217 (§4.7 Application, CONFIRMED); proof in analysis/reports/ + findings_register.",E2,E2,,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
FS_DEL_RA_004,Content,Deletion Recovery,Recovery efficiency gradient: Trash Table (1 read) < checkpoint diff (2 traversals) < orphan scan (full volume). Updated by E64: this gradient IS the mode boundary — recovery mode = Trash + checkpoint-diff + LIVE-page slack (cheap; pages already read by the tree walk); --full adds the orphan-PAGE slack scan (full-volume; the slow half where older deletions live).,post_thesis_analysis,,3.4;3.14,2026-06,High,No,CONFIRMED,"Promoted from thesis findings register #231 (§4.7 Application, NEW); proof in analysis/reports/ + findings_register.",CONFIRMED,"Promoted from thesis findings register #231 (§4.7 Application, NEW); proof in analysis/reports/ + findings_register.",E2,E2,,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
FS_VOLI_RA_001,File System,Volume Information,"$VOLUME_INFORMATION (OID 0x500 blob) carries TWO independent versions: volume version at +0x80/+0x81 (echoes VBR+0x28, changes only on format upgrade) and a per-mount DRIVER-version stamp at +0x82/+0x83 = the HIGHEST ReFS driver build that ever mounted the volume (0x0403 v3.4, 0x0e03 v3.14 RTM, 0x0f03 Insider 29574). A v3.4→Win11-RTM upgrade gives vol=3.14/drv=3.14 (EQUAL); drv=3.15 appears ONLY after an Insider mount (forensic: detects Insider exposure). Writers: SetVolumeMounted (+0x82), SetAndGetVolumeTimes (+0xA0). No volume GUID stored in the blob. RD-verified across 7 images",post_thesis_analysis,,3.4;3.14,2026-06,High,No,CONFIRMED,"Promoted from thesis findings register #306 (§4.2 Volume, NEW); proof in analysis/reports/ + findings_register.",CONFIRMED,"Promoted from thesis findings register #306 (§4.2 Volume, NEW); proof in analysis/reports/ + findings_register.",E2,E2,,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
MD_DATA_RA_011,Content,Data Extents,"MI $DATA (type 0x80, non-resident) value layout confirmed/refined (offsets below are the v3.7+ layout): inner_hdr_size@0x00=0x88 (all versions), summary_size@0x0C=0x200 on v3.14+ / 0x1A0 on v3.4-3.10 (NOT 0x30 — that is the resident SI $DATA), stream_size@0x38, vdl@0x40, disk_alloc@0x48, version-count+sparse-flag@0x50 (low31=version count=1, bit31=sparse; NOT cluster_count), extent record at +0x88 (subrec 0x28, flags 0xe00, extent_count@0x14, 24-byte extents). VERSION-SCOPING (E72, disk 2026-08-29): on v3.4 the four size fields shift +4 — total_alloc@0x34, stream_size@0x3C, vdl@0x44, disk_alloc@0x4C=0 (allocation carried by total_alloc@0x34 alone); v3.7+ use the 0x30/0x38/0x40/0x48 offsets shown. The original 84K/31,678-record census was v3.14/Insider-only (anchored on val[0x38]==file_size, which self-excludes v3.4); refsprogs corroborates (/* v1.0-3.4: 0x3C v3.5+: 0x38 */). No forefst impact (v3.4 size from type-0x30 value+0x58, extents decode independently). Key sub_id namespace: 0x8=stream metadata, 0x1000=live, 0x1001+=CoW/snapshot versions. RD: 84K MI records",post_thesis_analysis;raw_analysis,,3.4;3.7;3.9;3.10;3.14,2026-08,High,No,CONFIRMED,"Promoted from thesis findings register #307 (§4.4 Structures, ENRICHED); proof in analysis/reports/ + findings_register. E72 version-scoping via all-version holder census analysis/reports/refsprogs_audit_2026-08-29/harnesses/census34.py.",CONFIRMED,"Promoted from thesis findings register #307 (§4.4 Structures, ENRICHED). E72: v3.4 stream_size@0x3C 257/257 win10refs8g + 257/257 win10refs110g; summary_size@0x0C=0x1A0 on v3.4/3.7/3.9/3.10, 0x200 on v3.14/Insider.",E2,E2,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,unknown,
MD_ATTR_RA_018,Metadata,Attributes,"Type 0xB0 attribute-flag bit 0x0800: E2-confirmed bit-gate (win11 L389035: if val[0x02] bit 0xB set, SCB+0x98 |= 0x80; sparse/CoW-related). Its independent SEMANTIC cannot be confirmed from raw disk — 0x0800 NEVER appears isolated (only within a snapshot's 0x1C00). The prior ""dedicated non-resident MinStore stream"" reading is REFUTED; 0x0400=HasSnapshot (RD 1:1 with 29 snapshots), 0x1000=stream-set member (gates GetFileStreamSetId)",post_thesis_analysis,,3.4;3.14,2026-06,High,No,CONFIRMED,"Promoted from thesis findings register #308 (§4.4 Structures, CORRECTED); proof in analysis/reports/ + findings_register.",CONFIRMED,"Promoted from thesis findings register #308 (§4.4 Structures, CORRECTED); proof in analysis/reports/ + findings_register.",E2,E2,,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
MD_SI_RA_016,Metadata,Standard Information,"DataSize ($SI+0x38) rounding rule resolved: it is the $DATA stream's ALLOCATED size (8-byte-aligned), NOT the logical file size. Verified DataSize == SI-$DATA allocated_size (val+0x18) 19/19; == align8(file_size) 18/19; == raw file_size only 2/19 (the already-8-aligned cases). The ""~2% alignment padding"" in E26 is exactly non-8-aligned content. Exact logical size = $DATA sub-record file_size (val+0x20). Refines E26",post_thesis_analysis,,3.4;3.14,2026-06,High,No,CONFIRMED,"Promoted from thesis findings register #314 (§4.5 Metadata, ENRICHED); proof in analysis/reports/ + findings_register.",CONFIRMED,"Promoted from thesis findings register #314 (§4.5 Metadata, ENRICHED); proof in analysis/reports/ + findings_register.",E2,E2,,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
FS_VOLI_RA_002,File System,Volume Information,"$VOLUME_INFORMATION (OID 0x500 blob) +0x84 flags decoded (RD, 110 images): 0x180 (bits 0x080|0x100) on v3.4/3.7/3.9 = pre-v3.10 format marker, PERSISTS across upgrade (upgraded v3.4->v3.14 keeps 0x180); 0x000 on native v3.10+ (v3.10/3.14/Insider); 0x200 = heat-gathering disabled (disableheatgathering tunable). The 0x180->0x000 transition is a THIRD independent native-vs-upgraded discriminator (with CHKP bit 0x080 and the +0x82/0x83 driver stamp)",post_thesis_analysis,,3.4;3.14,2026-06,High,No,CONFIRMED,"Promoted from thesis findings register #315 (§4.2 Volume, NEW); proof in analysis/reports/ + findings_register.",CONFIRMED,"Promoted from thesis findings register #315 (§4.2 Volume, NEW); proof in analysis/reports/ + findings_register.",E2,E2,,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
FS_CHKP_RA_014,File System,Checkpoint,"CoW checkpoint-comparison limitation RD-verified across the corpus: the two CHKP copies ALWAYS decode to identical 13-root pointer lists — confirmed on clean (win11refsmini), corrupted (win11refsmini_aftercorruption + reopened-with-v3.4), busy (win11refs2tmillionsofactionsv2, vclocks 293/292), and pre-salvage (vclocks 662/662) images. The copies are NOT otherwise identical, and 'only the virtual clock + per-page checksums differ' is wrong: byte-compared on 18 volumes (4 x v3.4, 14 x v3.14; 4K, 64K and 4Kn; clean, corrupted, busy and lab), every pair differs in 11-15 bytes, and on 18/18 those include fields that are neither a clock nor a checksum - the ALLOCATOR clock at +0x68 (differing by exactly 1 on 18/18: lab314_main 372 vs 373, win10refsmini 39 vs 40, winsider 1769 vs 1770), the page self-LCN at +0x20 (lab314_main 0x2874 vs 0x1e3f4) and the self-descriptor LCN (+0xD0 on v3.4, +0xE0 on v3.14 4K, +0xE8 on winsider). The virtual clock differs at both +0x10 and +0x60. Example diff map, win11refsmini: 0x10, 0x20-0x21, 0x60, 0x68, 0xe0-0xe1, 0x108-0x10b. So checkpoint comparison yields NO prior whole-tree state on cleanly-unmounted-or-remountable volumes; a genuine mid-transaction crash capture (absent from corpus) is required. CAVEAT: comparing raw CHKP bytes is misleading (clock/checksum always differ) — must decode + compare root page-refs (parse_chkp). Recoverable prior states on a clean volume come from snapshots (#321) + superseded pages (deletion_recovery), not the alternate checkpoint. Confirms copy_on_write.md",post_thesis_analysis,,3.4;3.14,2026-06,High,No,N/A,"Promoted from thesis findings register #324 (§4.2 Volume, CONFIRMED); proof in analysis/reports/ + findings_register.",CONFIRMED,"Promoted from thesis findings register #324 (§4.2 Volume, CONFIRMED); proof in analysis/reports/ + findings_register.",E3,E3,,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
FS_OTBL_RA_008,File System,Object Table,"Embedded-record files have NO Object-Table OID. A embedded-record file's dir-entry value+0x08 (""target_oid"") is a VERSION-DEPENDENT sentinel (NOT in obj_map) whose high nibble tracks the value-format era: v3.4=0x18000000001, v3.7/3.9/3.10=0x1c000000001, v3.14=0x1e000000001 (disk-verified 2026-07-05: win10refsmini v3.4=0x18..., win11refs2g v3.14=0x1e...) — the file lives entirely inline in the parent directory's type-0x30 row, addressable only by (parent_oid, filename) = path. Non-resident DIRECTORIES get their own OID + B+-tree (value+0x08 = the directory's own OID); non-resident FILES do NOT — value+0x08 is the home-dir backref (the OID of the directory the file was first created in, a DIFFERENT object shared by all of a file's hard-link names; #340/FN_LINK_002/master 813/#335), and a file's content lives in type-0x40 backing/extent records reached via (home backref, child ordinal), not an Object-Table OID of its own. CORRECTED 2026-06-27: the prior 'Non-embedded-record files/dirs DO get their own OID + B+-tree' over-generalised (conflated split-record files with split-record directories) — this is the parser artifact behind the forefst/refsanalysis --oid file<->dir OID collision (a file reported with a directory's OID), fixed in the tools 2026-06-27 (analysis/reports/forefst_oid_bug_2026-06-27/). Confirmed across the corpus (every embedded-record file = 0x1e000000001). Tool impact: added `details <path>` (forefst resolve_path + cmd_details) to give full details of embedded-record files by path since `--oid` cannot reach them; offsets verified against the lister 15/15. Also added `snapshots --file/--extract` (export a file's snapshot versions), `deleted --extract` (export recovered deleted/old rows), and a summary upgrade flag (CHKP native-bit 0x080 + $VolInfo stamp ⇒ ""APPEARS UPGRADED""). 234/234 matrix tests pass on 26 images",post_thesis_analysis,,3.4;3.14,2026-06,High,No,N/A,"Promoted from thesis findings register #327 (§4.3 System, NEW); proof in analysis/reports/ + findings_register.",CONFIRMED,"Promoted from thesis findings register #327 (§4.3 System, NEW); proof in analysis/reports/ + findings_register.",E3,E3,,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
AP_LGFL_RA_009,Application,Log File,"MLog redo-opcode table routing: v3.7–v3.13 must use the V314 table, not V34. On-disk evidence (win1121h2test v3.7, win1122h2test v3.9, win1123h2test v3.10) shows v3.7+ all emit the v3.14 opcode SUBSET — including the 0x1D–0x1F stream ops absent from v3.4 — and never use the version-ambiguous 0x16/0x17, so V314 names them correctly. The tool's `vmin >= 9` boundary mis-routed v3.7 to V34, leaving 78 of 3990 records (the 0x1F = RedoUpdateStreamSummary ones) unresolved. Fixed to `vmin >= 7` (helper `_redo_ops_for_version`); RD-validated to 0 unknown opcodes across all 83 corpus images with an MLog log. Cross-source check (item 2): USN file_oids overlap live $SI objects 75–100% (the remainder are deleted files preserved in the USN journal); MLog's `object_id` is a table/path namespace (not the file-OID), so the super-timeline correctly joins MLog by path, USN/$SI by OID. No inconsistencies found. (No v3.7–v3.10 driver exists to decompile; routing is RD-grounded.)",post_thesis_analysis,,3.4;3.14,2026-06,High,No,CONFIRMED,"Promoted from thesis findings register #330 (§4.6 Log, NEW); proof in analysis/reports/ + findings_register.",CONFIRMED,"Promoted from thesis findings register #330 (§4.6 Log, NEW); proof in analysis/reports/ + findings_register.",E2,E2,,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
FS_VBR_RA_013,File System,VBR,"Primary and backup boot sectors can DIVERGE in the version field, and the driver cannot detect it. ReFS reads sector 0 (primary) then the last LBA (backup) at mount (RefsReadBootSector win11 @135981 / ReadBootSectorForMount insider @231636; backup LBA = totalSectors−1 = `*(VCB+0x1f0)−1`). Validation `RefsIsBootSectorOurs` (win11 @483985) is self-contained — signature + the ROR1+ADD u16 self-checksum at 0x16 (exactly `forefst._vbr_checksum`, now confirmed against the driver) + geometry sanity (0x18/0x20/0x24). There is NO cross-copy CRC64 and NO virtual clock, so the two copies' relative currency is undecidable; the backup is consulted only when the primary read physically FAILS (the fallback loop breaks on read success regardless of validity). Forensic consequences (RD): (a) on a genuine upgrade the backup retains the ORIGINAL pre-upgrade version — confirmed on TWO independent real upgrades: win10to11refs4g_afterwin11mount (primary v3.14 / backup v3.4) and win1122h2test_afteropenedwithinsider (v3.14 / v3.9); only bytes 0x29 (minor) + 0x17 (checksum) differ. This recovers the EXACT original version (vs $VolInfo's ""pre-v3.10""). (b) The same divergence reveals VBR tampering: on hand-edited test images the primary carries the altered version (6.66, 3.15) while the backup holds the authentic 3.14. Static caveat (mechanism undetermined): the in-driver RW-mount upgrade dual-writes both copies (RefsWriteBootSector @135517, gated only by the SMR flag CmsVol+0xd34&0x800000), so both *should* be rewritten — yet the backup keeps the old version on every observed upgrade. The offline-tool hypothesis is ruled out: refsutil has no version-upgrade command (applets are dedup/snapshot/salvage/rollback/compression/triage/fixleaks/fixboot/iometrics), and its sole VBR writer `CFixBoot::Execute` (@140032770) also dual-writes primary + backup (decompiled). So the divergence seems to originate inside the driver's own upgrade path — the backup write apparently skipped on the upgrade transaction, or the version stamped via a sector-0-only path — but the exact reason is not pinned down. The empirical signal (backup retains the original version on 2 independent upgrades) is solid; the mechanism is not. Surfaced by `integrity` (Redundancy section reports the version mismatch + both versions, honestly ""upgrade or tampering"").",post_thesis_analysis,,3.4;3.14,2026-06,High,No,CONFIRMED,"Promoted from thesis findings register #331 (§4.2 Volume, NEW); proof in analysis/reports/ + findings_register.",CONFIRMED,"Promoted from thesis findings register #331 (§4.2 Volume, NEW); proof in analysis/reports/ + findings_register.",E2,E2,win10;win11.8115;win11.8521;win11.8972;win11.9444,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
FS_DEL_RA_005,Content,Deletion Recovery,"Deleted directory entries are recoverable in B+-tree NODE SLACK — and no current tool method gets them. Both tools' B+-tree iterators drive strictly off the live row-offset array `[thoff+astart, thoff+aend)`; the ~13 KB of slack in a 16 KB page is never read. Deletion (`CmsBPlusTable::DeleteFromIndex` @14001a610) removes only the offset-array slot and queues *delayed* compaction — row bytes are not scrubbed; they persist until a later CoW rewrite. RD (verified by hand): a slack scan of directory pages on win11refs2tmillionsofactions recovered 179 stale type-0x30 rows whose names are not in the live tree (real deleted names: xbpt_backup_report_125235.md, elvis_dir_zulu_272755, FVE2.{…}). `deleted --scan-pages` visits the right pages but still only follows their live offset array, so it misses these. BUILT as `deleted --slack` (v3.3.3, deletion-recovery ""Method 5""): brute-walks free-region row headers, decodes name+MACB+attrs, confidence-graded (high/medium/partial by timestamp sanity), cross-flags deleted vs prior-version. Validated 0 false positives on the clean baseline (all 19 recovered names genuinely absent from the live tree); robust v3.4/64K/corrupt. (Q8) UPDATED (E64, 2026-08-01): the orphan-page slack path now EXISTS as `deleted --full` (so ""no current tool method gets them"" no longer holds); the deleted-vs-prior split is IDENTITY-based (name + create_time), not a global name test; identical files deleted from several dirs are recovered once with all locations logged (recover-once/log-all); non-resident backings are joined by (file_id, home-backref)+size and carved (Feature C); a deleted parent dir groups children under $DELETED/DIR_OID_0x<oid>; write recoveries with `export deleted DIR`; the old `--slack` flag is now a silent no-op. Corpus-validated 0 false deletions across 4 USN images; all-image sweep 113 OK/0 issues.",post_thesis_analysis,,3.4;3.14,2026-06,High,No,CONFIRMED,"Promoted from thesis findings register #334 (§4.4 Content, NEW); proof in analysis/reports/ + findings_register.",CONFIRMED,"Promoted from thesis findings register #334 (§4.4 Content, NEW); proof in analysis/reports/ + findings_register. RD 2026-07-03 (win11refs8g/step6): the deleted DIRECTORY 'DeletedFolder' was recovered from orphan slack, correctly typed as a directory (attrs +0x40 dir-bit 0x10000000) with create read from the non-resident +0x10 = 2026-07-03T11:05:03.234, matching ground truth to 7 fractional digits; the >84 resident/residency discriminator is load-bearing (the old >=0x50 threshold would have read create from the resident +0x28). On-disk confirmation of review items E1/E2/E7. See analysis/reports/step6_validation_2026-07-03.md.",E2+RD,E2,all,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
FS_CHKP_RA_015,File System,Checkpoint,"The checkpoint Container-Table failover pair (root indices 7 & 8) is NOT bound to a fixed index→Table-ID order. Subtable A.4b lists root 7 = Container Table (ID 0x0B) / root 8 = duplicate (ID 0x0C); the claim-audit (probe `chkp_root_table`, owning-table id read at the table-root MSB+ page header +0x48) confirmed this on 106/110 images across many independent groups, but the 2 TB `win11refs2tmillionsofactions` volume carries the pair SWAPPED (root 7 → 0x0C, root 8 → 0x0B). The swap is present in the `_beforesalvage` image, so it is not a `refsutil salvage` artifact — the index→id binding of the failover pair is simply not guaranteed; the true invariant is the SET {0x0B,0x0C} at roots {7,8}. On the same volume root 12 (Small Allocator, expected ID 0x22) resolves to a Container-Table page (+0x48 = 0x0B) — a separate large-volume allocator-root anomaly, mechanism UNDETERMINED (open question). Same volume + 3 derivatives = 1 independent group; this refines A.4b (which shows only the common ordering) rather than overturning it. Surfaced by the P1 claim-audit (`forefstdev/docs/audit/`, FS_CHKP_016/017/021 scoped exceptions).",post_thesis_analysis,,3.4;3.14,2026-06,High,No,N/A,"Promoted from thesis findings register #337 (§4.2 Volume, NEW); proof in analysis/reports/ + findings_register.",CONFIRMED,"Promoted from thesis findings register #337 (§4.2 Volume, NEW); proof in analysis/reports/ + findings_register.",E3,E3,,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
MD_ATTR_RA_019,Metadata,Attributes,"Non-embedded-record file_attrs: the type-0x30 directory-entry POINTER (value+0x40) is an INCOMPLETE copy of the authoritative attrs in the type-0x40 backing record (value+0x48, the file's own $SI). It is a LOWER BOUND on the EA bit 0x40000, not a copy that always drops it: on winsider the cached copy is missing the bit for 8,141 names, carries it for 14,207, and never sets a bit the backing lacks (0 cases) [E92]. Across all sampled images the ONLY attribute bits that ever differ between pointer(+0x40) and size-matched backing(+0x48) are 0x40000 (EA) and the transient 0x20 (Archive). Tools must read +0x48 (or OR-in its EA bit) to report HasEA/FileAttributes correctly for split-record files. Embedded-record files unaffected (+0x48 already authoritative). See E56, E92.",raw_analysis;static_analysis,,3.14,2026-06,High,No,CONFIRMED,"The type-0x40 backing IS the file's own $SI (#327/FN_LINK_002; same layout as the embedded type-0x30 value, MD_SI_SA_001). EA-bit meaning per MD_ATTR_RA_003.",CONFIRMED,"All-disk re-measure 2026-06-30 (broad 4k/64k v3.4/v3.14 + winsider/specials/insider): XOR(pointer+0x40, size-matched backing+0x48) over every split-record file = exactly {0x40000, 0x20}; 0x40000 on 8140 files (winsider system files w/ $CI.CATALOGHINT/$KERNEL.PURGE EAs), 0x20 on 42 (sporadic, both directions; strict unique-size-match). forefst fixed 2026-06-29, refsanalysis 2026-06-30. | RE-MEASURED 2026-09-07 (E92) against the tool's own backing resolution: 8141 pointer-clear/backing-set, 14207 both-set, 0 pointer-set/backing-clear over 72,709 split names. BREADTH: a raw corpus scan for backing records with 0x40000 finds them on exactly 1 of 102 ReFS images (winsider); every WSL image carries EAs only on embedded records, so the effect is single-volume evidence.",E2+RD,E2,,yes,CONFIRMED,prior_work,3.14,3.4;3.14,"format_verified 3.4;3.14;insider recovered 2026-09-09 from the row's own note: ""All-disk re-measure 2026-06-30 (broad 4k/64k v3.4/v3.14 + winsider/specials/insider)"""
MD_DATA_RA_012,Content,Data Extents,"Type-0x40 backing record = the split-record file's own $SI/stream-summary, keyed (owner-dir OID, file_id) and resolved by size-match (E51). Value field map: +0x48 file_attrs (AUTHORITATIVE), +0x4C internal flags, +0x50 SecurityId, +0x58 file size, +0x60 allocated size, +0x68 LastUsn ($SI+0x40), +0x70 UsnJournalId (volume epoch when set, else 0), +0x7C ReparseTag mirror (valid if bit31). Same layout as the embedded type-0x30 value. structure_reference Subtable C.3a.",raw_analysis;static_analysis,,3.14,2026-06,High,No,CONFIRMED,"Backing = file's own $SI (#327/FN_LINK_002; field semantics per the $SI map, MD_SI_SA_001).",CONFIRMED,"RD-confirmed 2026-06-30 (winsider): SecurityId real (e.g. 8375163451), allocated cluster-aligned >= size, UsnJournalId constant 0x1dce1857f465fdd across files, +0x7C tag 0 on non-reparse. Drives forefst H3 columns (GroupSid/AllocatedSize/ReparseTag) + the non-resident EA/USN/SecurityId enrichment.",E2+RD,E2,,yes,CONFIRMED,prior_work,3.14,unknown,
FS_REPS_RA_004,File System,Reparse Points,"Non-resident reparse storage: the REPARSE_DATA_BUFFER is embedded in the file's type-0x40 backing record (the (owner-dir, file_id) record), and the tag is mirrored at backing +0x7C. v3.14: the target buffer is recovered from the file's own (home) backing. v3.7-v3.10: the backing carries ONLY the tag mirror; the target buffer lives in CoW-old pages, not the live tree (OPEN). (Resident reparse files embed the buffer in the type-0xC0 sub-record at value+0x0C; see C.8 Reparse Storage.)",raw_analysis;static_analysis,,3.14,2026-06,High,No,CONFIRMED,RefsGetReparsePointValue -> attribute 0xC0 -> FsRtlValidateReparsePointBuffer. Tag mirror @ $SI+0x54 / backing+0x7C (E21).,CONFIRMED,"v3.14 target recovered from the home backing (forefst H3 non-res ReparseTarget; collision-free oracle 375/0). v3.7-v3.10 mirror-only confirmed (target absent from the live tree). Resident buffer @ type-0xC0 v+0x0C disk-confirmed on 5 reparse files (win11refs2gtargeted, 2026-06-30).",E2+RD,E2,all,yes,CONFIRMED,prior_work,3.14,unknown,
FN_LINK_003,File Name,Hard Links,"Per-name MACB divergence across hard-link names — a ReFS-only, journal-independent timestomp cross-check. $SI MACB is stored PER NAME (per hard link), not per inode as on NTFS: each name is an independent type-0x30 non-resident row with its own Created(value+0x10)/Modified(+0x18)/Changed(+0x20)/Accessed(+0x28). A name-scoped SetFileTime writes the file's OWN RECORD at once, for every name; what diverges is each NAME'S INDEX ENTRY, a lazily refreshed cache the driver (RefsUpdateFileDupInfo) refreshes only for the name that was OPENED, so an un-opened sibling still holds its pre-stomp Created (E112). Divergence is evidence; agreement clears nothing (a read of the sibling produces it too); the stale entry is the name nobody OPENED, not the name nobody FORGED, so WHICH name holds the authentic birth is NOT established. The signal is perishable: any read of the stale sibling erases it. Stronger than NTFS $SI-vs-$FN (NTFS hard links share one $SI and cannot diverge). See E59; supersedes the '#335 one-timestamp-set / no cross-check' framing for hard-linked files.",raw_analysis,,3.14,2026-07-03,High,No,INFERRED,"Per-name type-0x30 rows + shared type-0x40 backing per FN_LINK_002/MD_DATA_RA_012 (E2 layout); the per-name index entry is refreshed only for the opened name (driver RefsUpdateFileDupInfo, S4 decompilation); the two-layer reading is E112.",CONFIRMED,"win11refs8g.raw (step6), File ID 0x1e (home 0x746): after Get-Item R:\blabla\f6.bin; $i.CreationTimeUtc='2011-01-01Z', the two hard-link names read f6.bin Created 0x01cba946d534c000=2011-01-01 vs f6_link.bin Created 0x01dd0b1d102d451c=2026-07-03 18:52:14 (true birth); shared type-0x40 backing value+0x28=2011-01-01 (matches the stomped name, not the clean sibling). USN journal corroborates (FILE_CREATE 2026-07-03) but is NOT required. forefst timestomp emits HARDLINK_MACB_MISMATCH for EVERY name of the diverging group -- flagging only one would assert the others are clean, and no evidence names an authentic one (E112).",E2+RD,E2,all,yes,CONFIRMED,prior_work,3.14,unknown,
MD_DATA_RA_013,Content,Data Extents,"Inline integrity checksum element (extends MD_DATA_RA_007): on a v3.14 4K-cluster CRC32-C stream each checksummed cluster is a run_length==1 extent (flag 0x1c00d0) immediately followed by an 8-byte element [CRC32-C(cluster):le32@+0][reserved:le32@+4]; 32-byte stride. CRC32-C (Castagnoli) poly 0x82F63B78 over the 4096-byte cluster (check CRC32-C('123456789')=0xE3069283). Checksum-type selector (CmsVolume+0x58 / 0xB0 val[0x38] E54): 1=CRC32-C/4B 2=CRC64/8B 4=SHA-256/32B 5=XXH64/8B; unset placeholder 0xABBAFFFE. SHA-256, 64K-cluster and v3.4 volumes carry NO inline element. le32@+4 is reserved/role-flags (0x58 first cluster, 0x28 interior). structure_reference C.6. CORRECTION (E86): the trailing element is 4 bytes (the CRC32-C), not 8 - the 4 bytes read as 'reserved' are 8-byte-alignment padding. The 32-byte step is roundup8(record_size 28) and holds only for run==1; a checksummed record with run>1 has record_size 24 + run*4 and its own aligned step. The CRC32-C algorithm, polynomial, per-cluster scope and checksum-type selector recorded here are unchanged and remain verified.",raw_analysis;static_analysis,,3.14,2026-08,High,No,CONFIRMED,Driver crc32c_4096 kernels @140080750/@140167bf0 (SSE4.2 crc32 + PCLMULQDQ folds 0xE417F38A/0x8F158014); ComputeOneChecksum @1400806fc uses the 4096-byte path only when span==0x1000; selector GetChecksumTypeForStreams @140077784 + BasicChecksumInfoForType. Workflow wf_f6f91d9b-5f3 (static+disk axes agree).,CONFIRMED,"391/391 elements le32@+0==CRC32-C(cluster), 0 counterexamples; zlib CRC-32 and 6 CRC64 variants matched 0/391. 249/249 (setintegritystreams1) + 142/142 (testmftecmd) verified. Tamper: 1 flipped byte -> exactly that cluster flagged (stored vs actual). Controls (integritystreams0/sha256/64k/v3.4) = 0 inline. forefst extract reports 'integrity: N/N CRC32-C-verified' + flags mismatches non-fatally.",E2+RD,E2,all,yes,CONFIRMED,prior_work,3.14,unknown,
MD_DATA_RA_014,Content,Data Extents,"Sparse hole in an inline extent map: a record with VLCN==0 is a zero-filled hole, NOT a readable extent (VLCN 0 -> PLCN 0 = boot region on every volume; cluster 0 is never file data). Sentinel carries flags bit 0x20 (0x180060/0x180064), file_vcn = hole start, run_length = hole length. 213 records corpus-wide, 0 in snapshot holders (all current-stream 0x1000). Reassembly/carve zero-fill; reading PLCN 0 injected the boot sector into recovered files (latent bug, fixed). structure_reference C.6 / E65.",raw_analysis,,3.14,2026-08,High,No,ENRICHED,Not driver-function-traced; VLCN 0 -> PLCN 0 = boot region confirmed on all corpus images (container-table identity for the reserved low region); analogous to NTFS LCN-0 sparse runs.,CONFIRMED,"213 vlcn==0 records across the corpus (sparse_extent_sweep.py), 0 in snapshot holders. zero.bin ext0 (fvcn0,vlcn0,run1,flags0x180060): reading VLCN 0 = ...ReFS...FSRS... boot bytes while the file is zeros; reassembly zero-fills cluster0 (no boot leak, verified). Carve baseline leaked the boot sector, now fixed (snapshot_sparse_fix 2026-08-05).",RD,NONE,,yes,CONFIRMED,prior_work,3.14,unknown,
MD_USN_RA_005,Metadata,USN Journal / FileId,"The FileId ordinal at $SI+0x58 (= the low 8 bytes of the 128-bit Windows file id) is the OBJECT'S OWN ordinal, not a 'next' counter: on lab314_main the embedded type-0x30 value+0x80 equals Windows' FileIdLo from fsutil on 4,645 of 4,645 rows matched by (FileIdHi == containing-dir OID, name), 0 disagreements, and all 27 ground-truth directories read FileIdLo 0 (a directory's own type-0x10 value+0x80 is 0 on 26 of 26 that have such a row). The increment-only counter lives elsewhere - the Object-Table payload u64@+0x50 in 88-byte OT values, which is >= the maximum child ordinal on 22/22 lab314_main and 173/173 win11refstestmftecmd directories. The ordinal is monotonically allocated and never re-used after a deletion (increment-only): a deleted file's reference (containing-dir OID, FileId) is never re-issued to a later file, so USN correlation on that reference is TEMPORALLY stable (no aliasing of a deleted file to a later one across the journal's history). This TEMPORAL no-reuse is DISTINCT from SPATIAL object identity: the ordinal is per-directory scoped (its value recurs across sibling dirs, so it needs the OID), and for HARD-LINKED files the object is resolved by (owner-dir, file_id) SIZE-MATCH (FN_LINK_002 / #340 / E51), not by the ordinal alone. Extends MD_USN_RA_002; cross-ref MD_SI_RA_008.",raw_disk;static_analysis,,3.14,2026-08,High,No,CONFIRMED,"Increment-only counter: RefsMoveFile increments the parent's NextFileId and stamps the new child; RefsGetNextFileIdFromObjectTable reads the PERSISTED object-record counter (no free-list); RefsDeleteFileId2 / RefsQueueTriageForDeadFileId only remove the type-0x20 FileId-index entry on delete -- nothing decrements or recycles a freed ordinal. RefsPackFileId @140079440 packs (entry ordinal, containing-dir OID) into the NTFS-style 128-bit FileId.",CONFIRMED,"USN behavioural evidence, restated after re-measurement. NO-REUSE HOLDS: a strict FILE_CREATE after a FILE_DELETE for the same (home_oid, file_id) occurs 0 times on every volume measured (winsider's 1,147 apparent hits are single records carrying both flags in one cumulative reason mask, not two events). MONOTONIC ORDERING DOES NOT: on winsider ($J parses to 217,892 records, 18,211 distinct first-FILE_CREATE references) 111 references carry an ordinal LOWER than one already created in the same directory - dirs 0x90ed 69, 0x888f 32, 0x90e8 7, 0x8b01 2, 0x89ac 1 - e.g. 0x90ed runs 4206..4774 then interleaves 4137, 4775, 4776, 4138, ... all inside a 7 ms window. These are not recycled ordinals: 0 of the 111 have any journal record before their first FILE_CREATE and 0 carry a second distinct filename. win11refs8g, one of this row's own cited volumes, has 1 further inversion. So the ordinal is not issued in journal order; do not infer creation order from it.",E2+RD,E2,all,yes,CONFIRMED,prior_work,3.14,unknown,
MD_USN_RA_006,Metadata,USN Journal,"FileRef=(HomeOid,FileId) is the driver-canonical 128-bit file reference (RefsPackFileId: word1=creation/home-dir OID, word0=per-directory ordinal) and is INVARIANT across rename AND cross-directory move — only the ParentFileReferenceNumber changes. The file's type-0x40 backing stays in the creation dir. (home,ordinal) is far more unique than (parent,ordinal). Spatial counterpart to the temporal no-reuse of MD_USN_RA_005/E66; see E68.",raw_disk;static,,3.14,3.14;3.10;3.7,High,No,CONFIRMED,"RefsPackFileId packs word0=ordinal + word1=dir-OID (bijective; RefsUnpackFileId). RefsMoveFile migrates only the type-0x20 FileId-resolution row and never rewrites the FCB reference word [fcb+0x58]+0x100, so word1 is frozen at creation. F-1 SA1/SA3, f1_investigation_2026-08-09.",NEW,"1,858 cross-dir moves / 9 v3.14 images: FileRef home+ordinal unchanged in every case, ParentFileReferenceNumber flips old->new (usn_move_invariance.py, move_invariance_breadth.py). Moved file's type-0x40 backing found in the home dir not the current parent (backing_stays_in_home.py); on-disk moved entry carries value+0x08=creation dir (Generate-FSActivity.ps1 home 0x9586, now parent 0x9e25). (home,ordinal) vs (parent,ordinal) collisions: winsider 2 vs 1135. Report fileref_move_2026-08-12.",E2,E2,all,yes,CONFIRMED,this_project,3.14,3.7;3.10;3.14,"register note: 1,858 cross-dir moves / 9 v3.14 images: FileRef home+ordinal unchanged in every case, ParentFileReferenceNumber flips old->new (usn_move_invariance.py, move_inv"
FN_LINK_004,File Name,Hard Links,"The rare (home,ordinal) cross-file FileRef 'collision' is a HARD LINK — one object with multiple names (single home-owned type-0x40 backing + one embedded type-0x39 back-pointer per name = the authoritative name list); the differing per-name sizes are stale value+0x38 copies. NOT deduplication or block-clone. Proven organically (winsider) and synthetically. Refines the 'synthetic-corpus artifact' wording of E66 and the 'two distinct files' example of §J (E69).",raw_disk;static,,3.14,3.14;3.10;3.7,High,No,CONFIRMED,"RefsLinkFileToSelf copies the (home,ordinal) identity into each name and adds a type-0x39 back-pointer, allocating no new stream. RefsDuplicateExtents (block-clone) and the dedup/WOF reparse paths call NO FileId/name allocator, so they cannot mint a shared (home,ordinal). insider + win11 RTM. F1_FINDING.md.",NEW,"winsider 0x9d84:0x2 (SplashScreen 0 / Wide310 1397) = 1 backing (1397) + 2x type-0x39; xbpt (home 0x708 ordinal 8): xbpt_romeo_output 97673 / xbpt_hardlink_audit 239973 = 1 backing (97673) + 2x 0x39, reproduced 3 images; every different-size (home,ordinal) group -> exactly 1 home-owned backing (44 groups, 0 multi-backing, ReFS 3.7-3.14). Dedup EXCLUDED 10-axis: is_dedup=FALSE, backing internal_flags bit 0x02 clear, no 0x80000013/0x80000017 tags, before/after Enable-DedupVolume unchanged (3==3), inverted correlation, 2 real-dedup images real=0. Reports f1_investigation_2026-08-09; f1_fileid_collision.py, verify_single_object.py.",E2,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,this_project,3.14,3.7;3.10;3.14,register note: winsider 0x9d84:0x2 (SplashScreen 0 / Wide310 1397) = 1 backing (1397) + 2x type-0x39; xbpt (home 0x708 ordinal 8): xbpt_romeo_output 97673 / xbpt_hardlink_audi
FS_MOVE_RA_001,File System,Move / Relocation,"A cross-directory MOVE forces the object's record to be SPLIT out of its name row - key_flags 0x01 -> 0x02 with a type-0x40 backing - and that split is one-way (CORRECTED by E87: the original wording said 'forces the file NON-RESIDENT', which reads as a statement about where the DATA is; the data does not move at all). RefsMoveFile re-homes only the type-0x30 NAME and the type-0x20 FileId-resolution index, and freezes the (home, ordinal) FileRef (home = creation dir; E66/E68). Only the SPLIT type-0x30 layout (Sec C.3) carries the per-name home-backref at value+0x08 that holds the frozen creation-dir home - the EMBEDDED layout (Sec C.2) has no such field. Corollaries: a same-directory RENAME keeps the record embedded; a COPY is a new object; a cross-directory HARD LINK likewise forces the split; a move-back stays split. Identity findings unaffected; only the residency wording was wrong. That the split is REQUIRED by the +0x08 field is an INFERENCE (see FS_MOVE_RA_002).",static;raw_disk,,3.14;3.10;3.7;3.4,3.14,High,No,CONFIRMED,"RefsMoveFile (win11 @1400e9500 / insider @14010f2d4 / win10 @1c00b4800) does NOT call RefsRemoveLink or RefsAddLink: 0 references to either in the body, in all six builds. Its named callees are MsReparentChildTable (exactly 1 call, present in win10 too), RefsCreateFileId2 x4, RefsDeleteFileId2, RefsConvertToStandardInfoExternalId and RefsPersistNextFileId (win10 additionally RefsAllocateFileKey, MsUpdateObjectRecordPayload, MsUpdateDataWithRoot). This is not an inlining artefact: both symbols have their own bodies in every build's index (8115 RefsRemoveLink @14024a2cc 324 B, RefsAddLink @140246cc8 38 B) and are called from other functions in the same build (11 and 4 callers respectively), so they were not dissolved into callers. Established as 'not called by name from RefsMoveFile in 6 of 6 builds'.",NEW,"Controlled before/after (win11refs8gtestmove_{before,after}move.raw + USN + moves.txt, 2026-08-16): move.txt 16B resident->non-resident, FileRef 0x761:0x2 (home 0x761 frozen, parent->0x762); hl.txt resident->split-record hlc2 (shared 0x761:0x3); movesamedir->movedsamedir stayed resident; copied.txt = new File ID; haha2_10021 move-back stayed non-resident. Corpus 134/134 cross-dir-moved files non-resident (win11refs8g 42, testmftecmd 92); sub-ceiling moved files still extent-backed while equal-size non-moved size-0 files resident. Ordinal: testdeletion2 10001-create+1112-delete -> 10190 distinct, strictly monotonic, 0 reuse, new>max-deleted. Reports move_residency_controlled_2026-08-16.md, externalfileid_disk_2026-08-16.",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,this_project,3.4;3.7;3.10;3.14,3.14,"register note: Controlled before/after (win11refs8gtestmove_{before,after}move.raw + USN + moves.txt, 2026-08-16): move.txt 16B resident->non-resident, FileRef 0x761:0x2 (home"
MD_DATA_RA_015,Content,Data Extents,"Embedded-record file whose $DATA is EXTENT-backed ('inline holder'): a key_flags=0x01 type-0x30 value (long, >84 B) holds the file's record, while the $DATA stream's extent map lives in the embedded type-0x80 holder (descriptor 0x00010028). This is simply what an extent-backed file looks like when its record was never split out - i.e. never moved and never hard-linked. On format <=3.10 it is the form of EVERY embedded row (100%), because main $DATA is never inline there; on 3.14 the share is a property of the VOLUME, not of the format, and the single corpus-wide figures previously given here (8.1% and 34.6%) are composition aggregates dominated by the large Windows images. Measured per volume: embedded rows whose $DATA is extent-backed run 0.0% (win11refsmini 0/9), 13.2% (lab314_main 617/4,657), 30.0% (winsider 14,353/47,909), 82.5% (win11refstestmftecmd 768/931) and 96.2% (lab314_64k and lab314_4kn 611/635). Of ALL extent-backed records, the embedded share runs 0% (win11refsmini), 34.7% (winsider), 75.9% (testmftecmd), 99.7% (lab314_main) and 100% (lab314_64k/_4kn). Quote a range, or a named volume - never one number for the format. The embedded value is a multi-level B+-tree, so an outer-level parse finds no $DATA row and reports size 0 despite on-disk data (E73 descends it).",static+raw_analysis,,3.4-3.14,2026-09,High,No,ENRICHED,"Extent runs are the same 24-byte format the driver CmsStream::LookupAllocation reads (E2, MD_SNAP_RA_003); holder descriptor 0x00010028 and residency-via-disk-alloc are E2/RD (structure_reference C.6). Detection is forefst _multilevel_extent_backed_size / _current_stream_extent_backed (F5): get_resident_file_size looks for the 0x80000001 $DATA row in the embedded B+-tree and finds none at the outer level; size@0x58/alloc@0x60 at fixed header offsets. Leaf extents = the rows in the holder's MSB+ B+-tree node index array (node table header tbl[4]/tbl[8]; inner-node bit tbl[3]&0x100) - the standard node structure walk_bplus/_walk parse (E2). forefst's scan instead drops rows with flags & 0x04 (aggregate/fence entries that sit OUTSIDE the leaf index array; on xbpt_archive_romeo the 0x04 row's vlcn==first-leaf and its run spans the leaves), proven IDENTICAL to the node-index-array decode (RD: 855/855 holders, 0 diff). CORRECTION 2026-08-21: an earlier draft mis-attributed bit 0x04 to the B+-tree DIRECTOR key (CreateDirectorKey/CompareKeys test bit 0x04 of a KEY word - a DIFFERENT field, the row key not the extent flags@0x08); the operative fact is node index-array membership (E2 structure) with flags & 0x04 as its RD-equivalent proxy (structure_reference C.4a/C.3b).",CONFIRMED,"All-disk re-measure 2026-08-20: v3.4/3.7/3.9/3.10/upgraded gain non-resident classification (win10refs8g 0->259; win1121h2test 183->217; win1122h2test 249->308; win1123h2test 142->178); native pure-v3.14 unchanged; 0 regressions across 122 images. Safety invariant every inline-holder hit has resident-size==0: 0 violations over 8 images incl. natives; per-image hit counts match dataruns deltas (1/257/59/17/259). Extent map is a ReFS B+-tree node walked via its trailing u16..0xffff INDEX ARRAY (leaf flags 0x18004x/5x/6x; index/summary rows flag-bit 0x04 excluded = coarse duplicate whose vlcn==first-leaf's, proven on xbpt_archive_romeo); decodes fragmented/multi-node files and the SAME holder layout in the type-0x40 backing (C.3a). win10refs8g 256/259, v3.9 0->225, v3.10 0->129 with decoded extents; native v3.14 BYTE-IDENTICAL (incl. integrity/snapshot/64k, dataruns+extract). Full corpus 122 imgs/36841 holders: 0 regressions, +1337 recovered, all 4 decoder disagreements = new decoder CORRECTING the old (2 harmless generator-identical-content, 2 fixing silent corruption: xbpt_lima_oscar fvcn 0 twice, xbpt_index_uniform a zero first-cluster vs real GFSAREPLAY). Corruption guard = extents emitted only for an exact contiguous file_vcn cover [0,alloc/cluster); else none (clean extract fail), never wrong bytes. Cross-image byte-exact vs CTF-validated v3.4 twins. Residual (extent tree spanning child pages on separate LCNs) fails cleanly. DELETED-RECOVERY 2026-08-21: the same inline holder survives in page slack after deletion, so forefst `export deleted --carve` reuses this cover-guarded index-array decoder to carve non-resident deleted files on v3.4-v3.10/upgraded (previously 100% metadata_only: win10refs8g 0->202; corpus +5961 carves over 40 imgs, 0 lost vs prior tool, 0 zero-byte; ground truth = lab SetLength+GFSAREPLAY content, byte-exact). Also fixed a latent buffer-shrink in the carve reader: a past-EOF/out-of-volume plcn returned an empty read that TRUNCATED the output buffer (slice-assign shrank the bytearray) -> len-safe slice-assign; stale out-of-volume maps now yield NO file, not a 0-byte one. | RE-MEASURED 2026-09-04 on corpus manifest r2 (79 distinct volumes): embedded-and-extent-backed rows = 3,153/3,153 (v3.4, 100% of embedded), 442/442 (v3.7), 701/701 (v3.9), 250/250 (v3.10), 34,272 of 421,109 (v3.14, 8.1%). Share of ALL extent-backed rows that are embedded: 100% (v3.4), 63.6% (v3.7), 67.0% (v3.9), 47.7% (v3.10), 34.6% (v3.14). The words 'rarely native v3.14' and 'embedded-layout' are withdrawn: it is neither rare nor a residency statement. RD 2026-09-07 (lab314 volumes, PLAN v5 Part C): witnessed on lab314_main / _64k / _4kn (Win11 24H2, ReFS 3.14, 4 KiB / 64 KiB / 4Kn), against ground truth written on the volumes by the operator (inventory.csv 4,657+626+626 files 100% SHA-256; streams.csv per-ADS; hashes.csv; witness/hashes_t12r.csv; fsutil queryfileid). Content proof 5,908/5,909 byte-exact. T7/T7b: a move or a hard link splits the record and does NOT change residency -- t7_move.bin and a three-name link group are split x inline; the 3,000 B pair is split x extents. T6: the one-way ratchet witnessed by two 0-byte files of DIFFERENT residency -- t6_ratchet.bin (grown to 3,000 then truncated to 0) stays `extents`, t6_neverdata.bin (never written) is `inline`.",RD,NONE,all,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.7;3.9;3.10;3.14,"format_verified 3.4;3.7;3.9;3.10;3.14 recovered 2026-09-09 from the row's own note: ""All-disk re-measure 2026-08-20: v3.4/3.7/3.9/3.10/upgraded ... native pure-v3.14 unchanged"""
MD_USN_RA_007,Metadata,USN Journal,"The $UsnJrnl:$J change journal is a non-resident, extent-backed ROLLING LOG that FILLS its allocation, so the read length = the extent allocation (sum of run clusters = configured journal size, e.g. 32/128 MiB), NOT any stream-size field. The Change Journal value (OID 0x520) carries two 0x80000002 $DATA sub-records ($J + $Max), each tagged with the descriptor 0x000E0080 (a type tag, not a length). Each record self-validates (length@0x00, USN@0x28); a record USN = its byte offset in $J, so a file LastUsn ($SI+0x40 / type-0x40 +0x68) points to its most recent record and resolves exactly while inside the live window. Reading the full allocation is complete (0 duplicate USNs corpus-wide). Corrects a reader that capped $J at 0x000E0080=917632 bytes, truncating any journal larger than ~896KB (E71); structure_reference C.13.",static+raw_analysis,,3.14,2026-08,High,No,CONFIRMED,"USN_RECORD_V3 layout (len@0x00, USN@0x28, name-off@0x4A) is E2; descriptor 0x000E0080 = $DATA sub-record type tag (structure_reference C.3/C.6, MD_DATA_RA_011); $Max = type-0xF0 $LOGGED_UTILITY_STREAM carrying MaximumSize/AllocationDelta/UsnJournalID (schema 0x1F0).",CONFIRMED,"RD 2026-08-21, all 11 active-$J corpus images: stream_size==0x000E0080 on every one while alloc=32-128 MiB. Full read vs old tool: winsider 6481->217892, testmove 8703->33379, testmftecmd 6805->9371, attributes2 6874->8111; barely-used journals (win11refs2gtargeted 100, lasttests 46/53) BYTE-IDENTICAL (records fit the first ~896KB). Full read: 0 duplicate USNs, ~100% named, contiguous USN range. LastUsn->record positive control: winsider 13550/13550 in-window exact-offset match (was 706 in the truncated window). Trigger passwords.txt (FileRef 0x9c9f:0x7, LastUsn 66051560) now found: 4 records incl exactly USN 66051560 (reason 0x80008102). regress 18/18.",RD,NONE,,yes,CONFIRMED,prior_work,3.14,unknown,
MD_ATTR_RA_020,Metadata,Embedded Attribute System,"Multi-level embedded attribute tree (E73): when a file's attribute set outgrows one embedded node, the node inside the embedded type-0x30 value becomes an INDEX node - descriptor+0x0C level!=0 AND descriptor+0x0D bit0 set - carrying one row per child with an EMPTY separator key (key_offset 0x10, key_size 0x00) whose value is a 48-byte node reference (4x le64 LCNs; 0 and 0xFFFFFFFFFFFFFFFF are sentinels). The file's REAL attributes ($DATA 0x80, ADS/$SNAPSHOT 0xB0, $REPARSE 0xC0, and the type-0x0 key_len 0x50 ADS extent records of E61) live in the CHILD PAGE, not in the value; the outer level holds none of them, so an outer-level-only parse returns an empty list and reports a confident 'none' rather than an error. The child is reached with the ordinary page walk. Corpus: 1329 files / 19 of 99 images / 4094 records (2050x 0x80, 709x 0xC0, 548x 0xB0 ADS, plus 298/188/181 in the v3.4 marker-less form per E72 and 120 type-0x0 ADS-extent records), v3.4 to v3.14.",static_analysis;raw_analysis,,3.4;3.7;3.9;3.10;3.14,2026-09,High,No,CONFIRMED,"E2: CmsEmbeddedComposite::FindIndexHeaderInPage (win10 @1c0004b00) - the EMBEDDED-composite class - either takes the node directly at page+0x50+le32(page+0x50) or pushes a lookup stack and calls CmsBPlusTable::BinarySearchIndex, i.e. a real B+-tree index descent. Node-flag semantics are the documented A.2b ones (0x0C level 0=leaf/1-2=internal; 0x0D bit0=index).",CONFIRMED,"Ground truth: generate_validation_corpus_v2.ps1 writes 3+(n%3) ADS on each of 12 multibig_NN.bin; the pre-fix reader listed only 9 - multibig_05/08/11 (the 5-ADS files) reported ZERO. Descending their index row reaches an MSB+ page of 16 rows holding exactly big_1..big_5; post-fix 12/12 match the formula (48 streams) and the 5 recovered streams extract BYTE-EXACT (8192*k*5 bytes of marker MB05s{k}_, k=1..5). Five images go from 0 ADS to 35-60 (win1122h2test 0->60). Strictly additive: over all 1329 index-node values the pre-fix parse returned 0 rows - 4094 gained, 0 lost. forefst v1.8.0.",E2+RD,E2,win10;win11.8115;win11.8521;win11.8972;win11.9444,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,unknown,
FS_ALLOC_RA_001,Filesystem,Allocator Tables,"Allocator row format (E74), correcting four points of structure_reference B.2. (1) The bitmap row is VARIABLE length: bitmap_offset + roundup8(ceil(range_length/8)); 2072 B is only the range_length=16384 case (also 152 for 1024 clusters, 32 for 12 and 3). (2) +0x14 is TWO u8 fields, not a u16 'header size': bitmap_offset u8@0x14 (0x18 with a bitmap, 0x00 without) and a format byte u8@0x15 that is TIER-dependent - Container and Small are 1 on every version, Medium is 1 on v3.4 and 2 on v3.7+. (3) Flags BIT 0 means 'this row carries a bitmap' - the discriminator the driver uses; values 0x01/0x05/0x09 (bitmap) and 0x02/0x06 (compact) are consequences. (4) +0x16 is NOT a usable used-count: it is a driver-maintained allocated hint with 0xFFFF meaning 'the entire range', it disagrees with the row's own bitmap on 742 of 4634 rows, and must never be used for capacity arithmetic. +0x10 (free) IS authoritative but SATURATES at 0xFFFF (it does not truncate) - impossible on a bitmap row (range <= 16384), so it affects compact rows only. ROW ADDRESSES ARE PHYSICAL cluster numbers for the Medium tier (NOT stated by B.2, and a different question from B.2's Addressing column which describes how each tier's TABLE PAGES are reached): the Medium span is exactly [0, last-mapped-physical-cluster) on every image while the virtual space starts at first_container_id<<shift and is ~2x wider; live file-data extents are marked allocated 99-100% by translated PLCN vs 0-27% by VLCN. Container/Small row address basis NOT established. Authoritative free count: bitmap row = range_length - popcount(bitmap); compact row = 0 if free_u16==0 else range_length. Compact-row discriminator is free_u16 (0 = fully allocated, non-zero = fully free, and then free_u16 == min(range_length,0xFFFF)); this REFUTES the earlier working guess that the discriminator was +0x16.",static_analysis;raw_analysis,,3.4;3.7;3.9;3.10;3.14,2026-09,High,No,CONFIRMED,"E2, two independent driver generations. v3.14 CmsAllocator::BPlusRowToRegionEx (win11 @140092a60): start/length u64@0x00/0x08; (u32)u16@0x10 as free with NO sentinel handling; u16@0x12 flags; u16@0x16 into region+0x18 EXPANDING 0xFFFF to range_length; bitmap pointer = value + (u8)value[0x14] ONLY when flags & 1; tests (u8)value[0x15] > 1. Write side CmsAllocator::PersistRegion: value+0x16 = 0xFFFF iff region+0x18 == range_length, else the low 16 bits. v3.4 CmsGlobalAllocator::CopyBPlusRowToFv (win10 @1c0054f50) independently confirms all three: flags&1 gates the bitmap, (u8)value[0x14] is the bitmap offset, and the copy length is range_length>>3 - the variable bitmap size.",CONFIRMED,"RD 2026-09-01, all 95 ReFS images of the 99-image corpus, 7063 rows (5695 on pages claiming the tier's own table id). Row size matches the driver's formula on 4634/4634 bitmap rows. bitmap_offset is 24 exactly when flags&1 and 0 otherwise: 5695/5695. free == range_length - popcount on 4634/4634. Compact discriminator resolves 1061/1061 with 0 unexplained. Saturation proven not truncation: a 262144-cluster range (low 16 bits = 0) stores free=0xFFFF. Adversarial: every live metadata cluster on every image is marked ALLOCATED - 0 live-but-free across 95 images (those are PHYSICAL clusters, which is what first indicated the physical row addressing); live FILE DATA is 100% allocated on every healthy image tested (winsider 131385/131385). Address-space proof 2026-09-01: structural (Medium span == physical container extent on 4/4 images, virtual range differs) + behavioural (13917 live extents over 28 images: 99-100% allocated by PLCN per healthy image, 0-27% by VLCN). Probes: analysis/tools/analysis_scripts/allocator_probe.py, allocator_validate.py.",E2+RD,E2,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,unknown,
FS_ALLOC_RA_002,Filesystem,Allocator Tables,"Persisted allocator summary and tier resolution (E74). NEW STRUCTURE: each allocator table's ROOT PAGE carries a 416-byte summary (E110) ReFS maintains itself, at _SmsIndexRoot + u16@(_SmsIndexRoot+0x04) = page+0x50+u16@(page+0x54), observed at page+0x78 on every image. Read as u64[52]: slot 1 = clusters covered, slot 2 = clusters NOT ALLOCATED (Windows' Free Clusters plus its Total Reserved: 327,420 = 244,188 + 83,232 on win10refsmini; slot 1 - slot 2 = Windows' used; E114), slot 0 = format (2 on v3.7+ Medium, 1 on v3.4 Medium, 0 on Container/Small); slots 3-8 undecoded. It is the volume's OWN accounting and an independent check on any recomputation. TIER RESOLUTION: on v3.4 the tiers PARTITION (Medium intersect Container = 0 on all 9 v3.4 volumes; the live clusters Medium does not span are covered by Container) and are unioned; on v3.7+ Medium CONTAINS Container (intersection = the entire Container span on 86/86 volumes) so the tiers must NEVER be summed - Medium alone is the authority. COVERAGE LIMIT, restated after measurement: inside the DECLARED volume there is no unmapped tail - the container-mapped physical end (max container PLCN + clusters-per-container) EQUALS the VBR-declared cluster count (total_sectors at VBR+0x18 / sectors-per-cluster at VBR+0x24) on 11 of 11 volumes measured, across both cluster sizes and 507,904 to 4,026,515,456 clusters. The '48 MiB' figure is IMAGE end minus mapped end - space lying OUTSIDE the ReFS volume, not an area the allocator fails to cover - and it is an artefact of how the image was taken, so do not report it as a coverage gap.",static_analysis;raw_analysis,,3.4;3.7;3.9;3.10;3.14,2026-09,High,No,CONFIRMED,"E2: CmsAllocator::LoadAllocatorSummary (win11 @14003ef8c) requires 0x1A0 = 416 bytes (E110: the gate is `... < 0x1a0`; the earlier '3 x 0x80 = 384' was inferred, not read) from _SmsIndexRoot + u16@+0x04 into the allocator object; CommitAllocatorSummary is the write side, and RebuildAllocatorSummary / MarkAllocatorSummaryOutOfSync show the driver itself treats the summary as capable of going stale.",CONFIRMED,"RD 2026-09-01, 95 images / 281 tier-instances: the persisted summary agrees with the totals recomputed from the rows on 268, and ALL 13 disagreements are explained - 9 are v3.4 Medium (the summary spans the whole mapped volume while the Medium rows do not, under strict tier separation; the FREE counts still match exactly) and 4 are the damaged millionsofactions family (truncated container table: 16192 of 32767 contai | CENSUS 2026-09-20 (audit K126, REFUTED): slot 0 on the Medium root over the whole corpus - v3.4 reads 1 on 9 of 9 images; v3.7 (1), v3.9 (2), v3.10 (2) and v3.14 (100) all read 2. The discriminator holds on 114 volumes with no counterexample. K126 said 'the only 3.4 volume reads 2'; this corpus has nine v3.4 volumes and every one reads 1. The hand-edited 3.15 and 6.66 images also read 2, consistent with their being edited v3.14 volumes (E96/K051).",E2+RD,E2,all,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.7;3.9;3.10;3.14,
MD_ADS_RA_001,Metadata,Named Data Streams,"ReFS 3.4 ADS are stored with a MARKER-LESS embedded 0xB0 key (E75): the attribute type sits at key+0x08 and the UTF-16 stream name starts at key+0x0C, whereas from v3.7 an instance marker (0x80000002/0x80000001) occupies key+0x08, the type moves to key+0x0C and the name to key+0x10 - the two-form rule E72/MD_LK_RA_006 already recorded for embedded keys in general. A 0xB0 reader that matches only the marker form therefore reports ZERO alternate data streams on every v3.4 volume. Both forms must be accepted and the name read at the offset the matched form implies. The ADS-vs-snapshot discriminator is unchanged (StreamSummary val+0x10: 0=ADS, 2=snapshot, E61). Marker-less 0xB0 rows also survive on volumes UPGRADED from v3.4 (retained pre-marker entries), so the rule is not purely version-gated and must be applied per-record. These rows are typically NOT at the outer level of the embedded tree - they are reached only via the E73 index-node descent, which is why an outer-level census reported none.",raw_analysis,,3.4;3.14,2026-09,High,No,CONFIRMED,"Key layout is the E72/MD_LK_RA_006 two-form rule (marker era boundary v3.4<->v3.7, corroborated by unsound/refsprogs' explicit version>=3.5 branch). The 0xB0 attribute type and the StreamSummary ADS/snapshot discriminator at val+0x10 are the documented E61/C11 fields.",CONFIRMED,"RD 2026-09-01. win10refs2tspecials (v3.4, 2 TB): 176 live embedded 0xB0 rows, 0 with a marker, type 0xB0 at key+0x08, all val+0x10==0 (ADS). Reader reported 'ads (0)'; after accepting both key forms it reports 100 ADS-bearing files. Names match the generator exactly (Generate-FSActivity.ps1:1024 $stream='hidden_{0}' -f Rng.Next(1000,9999)) and CONTENT IS BYTE-EXACT vs the generator's two literals: test/xbpt_tango_archive_828215.dat:hidden_1514 -> 'Replayed ADS at 2026-05-16T11:51:08.7086168Z' (:733) and xbpt_data_quebec_921347.tmp:hidden_2136 -> 'Generated ADS at 2026-05-16T11:55:12.4451440Z' (:1024). Corpus census of marker-less embedded 0xB0 rows: 184 over five v3.4 volumes + 4 over two UPGRADED v3.14 volumes. Corpus effect: 7 images change, ALL 0->N (v3.4 win10refs110g 0->2, win10refs5g64k 0->2, win10refs2tspecials 0->100, win10refs8gsetintegristystreams1 0->2, win10to11refs4g_beforewin11mount 0->2; upgraded v3.14 win10to11refs4g 0->2, win10to11refs4g_afterwin11mount 0->2) - strictly additive, 0 lost. Refutes the 2026-08-29 differential audit's finding-#1 verdict ('0 ADS on 3.4 is the correct answer'), whose sweep predated the E73 child-page descent and so could not see these rows.",RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,3.4,"M3.2 2026-09-11: NARROWED. claimed 3.4;3.14 but the notes evidence one volume only - 'win10refs2tspecials (v3.4, 2 TB)'. No v3.14 witness is cited, so 3.14 stays claimed-not-verified."
MD_DATA_RA_021,Metadata,Data Extents,"Authoritative file size for a non-resident object (E76). A type-0x30 index-entry name (key_flags 0x02) caches the file size at value+0x38; the OBJECT's size is the type-0x40 backing's value+0x58. The cache is not refreshed on every update and can be stale in BOTH directions - larger than the object (an over-read that appends cluster slack) or SMALLER (a silent truncation, the dangerous case). Any size that gates a read or a write must resolve through the backing when one exists and fall back to the name's field only when it does not. Structurally impossible on v3.4, which has no type-0x40 rows and no key_flags 0x02 FILE rows (only kf=2 directories), so the rule keys on 'a backing resolves' rather than on the volume version.",raw_analysis,,3.7;3.9;3.10;3.14,2026-09,High,No,NOT_TESTED,Not isolated to a decompiled citation. The rule rests on the on-disk corroboration below: the backing's +0x58 agrees with the independently-decoded $DATA stream size where the name's cache does not. The type-0x40 backing layout itself is the documented C.3a structure.,CONFIRMED,"RD 2026-09-02, whole 99-image corpus: 83,176 key_flags 0x02 FILE rows, all with a resolvable backing; 190 STALE (v3.7:3, v3.9:4, v3.10:18, v3.14:165). In 190/190 the backing +0x58 equals the $DATA-derived stream size and the name +0x38 does not. Divergence runs BOTH ways: hardlink_audit_219848.cfg caches 239973 for a 97673-byte object; hardlink_mike_576693.csv caches 293302 for a 479429-byte object. Extracting the three largest under-read cases recovered 186127/274284/49480 bytes the previous code discarded, each 99.6% non-zero. v3.4 control: 0 type-0x40 rows and 0 kf=2 file rows on win10refs2tspecials/win10refs110g/win10refs5g64k. Fix validated corpus-wide: files --csv byte-identical 99/99; across the 39 affected images all 294 changed dataruns lines are size= lines with 0 extent/cluster changes; golden 90 rows all explained (51 warning-only, 39 size+warning, 0 unexplained).",RD,NONE,,yes,CONFIRMED,prior_work,3.7;3.9;3.10;3.14,unknown,
AP_LGFL_RA_010,Application,Logfile (MLog),"Every MLog LogCore record carries its own 8-byte integrity value at entry_header+0x08 (= page+0x80 where the entry header offset at page+0x54 is 0x78), and the algorithm is REPRODUCIBLE (E78). It is a four-way interleaved u64 XOR folded to 32 bits, not a CRC: zero the 8-byte field itself, then for each log block of le32(page,0x0C) bytes (0x1000 on every volume, independent of the cluster size) accumulate acc[i mod 4] ^= each little-endian u64, XOR the four accumulators together, and fold the result 64->32 as (v>>32) ^ (v & 0xFFFFFFFF). Blocks chain: the next block's acc[0] is seeded with rotate-left-1 of the previous block's result. A record is exactly one block, so in practice the seed is 0. The field is present on BOTH record types at entry_header+0x30: type 1 (control page) and type 2 (data record); no other type exists on disk. The per-volume constant at page+0x04 is a format/log-instance magic, NOT a checksum - reading it as a per-record checksum finds the same value on every record. Because it is an XOR fold it is an integrity check, not a signature: it detects any altered byte but is blind to a REORDERING of 8-byte words that keeps each word in its own lane (i mod 4).",raw_analysis,,3.4;3.9;3.10;3.14,2026-09,High,No,CONFIRMED,Written by LogCoreWriteDataRecord and verified by LogVerifyChecksumEntryHeader -> LogChecksumBlock on recovery; the log block size is hard-set to 0x1000 by MlLogOpenLog (record+0x0C).,CONFIRMED,"RD 2026-09-02, whole 99-image corpus: 599,039 of 599,039 data records recompute EXACTLY, plus 95 of 95 control pages - ReFS 3.4 through 3.15 and Insider, 4K and 64K clusters, 0 mismatches. Every MLog-signature page in every data area is type 2 (599,039 of 599,039); control pages are type 1. Adversarial: 2,000/2,000 random single-bit flips detected; a 0x01 flip at EVERY ONE of the 4,096 byte offsets is detected (0 blind offsets); corrupting the stored field itself is detected; 500 records carry 500 distinct values, so the check is not vacuous. End-to-end on a tampered copy, forefst mlog --stats reports the 2 flipped data records and the flipped control copy and leaves the intact copy verified. Shipped as forefst.mlog_verify_record().",E2+RD,E2,all,yes,CONFIRMED,prior_work,3.4;3.9;3.10;3.14,3.4;3.9;3.10;3.14,"M3.2 2026-09-11: the row's own notes state the scope outright - 'whole 99-image corpus ... ReFS 3.4 through 3.15 and Insider, 4K and 64K clusters, 0 mismatches'. Verified set to the claimed set."
MD_USN_RA_008,Metadata,USN Journal,"The $UsnJrnl:$J journal is an IN-PLACE RING, not an NTFS-style front-trimmed sparse file (E79). A record whose USN is X sits at byte offset X modulo the stream's ALLOCATION, the extents start at file VCN 0, and old records are overwritten where they lie. Consequence for a reader: the whole allocation must be read and the buffer may hold TWO generations at once - the newest records are at the START of the buffer and the oldest in the middle, so byte order is not time order and the highest USN legitimately exceeds the stream's size. Under the alternative (front-trimming) the live extents would begin past VCN 0 and offsets would be USN minus a base; that is refuted below.",raw_analysis,,3.14,2026-09,High,No,NOT_TESTED,Not isolated to a decompiled citation; the on-disk observation below is decisive on its own because it is a controlled discriminator between the two candidate models.,CONFIRMED,"RD 2026-09-02. 14 corpus journals, 338,439 of 338,439 records satisfy USN mod allocation == byte offset. The decisive case is winsider.raw, the only journal that has WRAPPED: allocation 33,554,432 B (32 MiB, extents (VCN 0, 6021 cl) + (VCN 6021, 2171 cl) = 8,192 clusters exactly), highest USN 74,459,840 = 2.22 windows, and ALL 217,892 records have USN >= the allocation, so the modulo is never the trivial identity. The buffer holds exactly two generations: generation 1 occupies offsets 7,352,320..33,554,168 and generation 2 occupies 0..7,350,976 - a clean partition with the write head at ~7.35 MB, which is the signature of a ring that has wrapped once. 0 violations. Non-circular: parse_usn_records derives `offset` from the linear scan position and reads `usn` from the record body, so the two quantities are independent. This settles the experiment the reference itself specified for the question.",RD,NONE,,yes,CONFIRMED,prior_work,3.14,unknown,
FN_DTBL_007,File Name,Directory Entries,"The size of a type-0x30 index-entry value (key_flags 0x02) is fixed AT WRITE TIME by the driver version that created the entry - 72 bytes (0x48) below v3.10, 84 bytes (0x54) from v3.10 - and is NEVER rewritten afterwards (E80). It is therefore NOT a property of the volume: a volume UPGRADED across that boundary carries BOTH layouts side by side, its pre-upgrade entries keeping the 72-byte form while the newer driver writes 84-byte entries for anything new. A reader must take the entry size from the row's own length, never from the volume version; keying on the version misparses every retained entry on an upgraded volume. All fields the tools read live at or below value+0x44, which is identical in both layouts, so a length RANGE test (0x48 <= len <= 84) is correct and version-independent.",raw_analysis,,3.4;3.7;3.9;3.10;3.14,2026-09,High,No,CONFIRMED,"The write-time gate is explicit in RefsAddFileNameIndexEntry: the value length is 0x48 when the version is below 0x309 and 0x54 otherwise. The driver applies it when ADDING an entry, which is why existing entries survive an upgrade unchanged.",CONFIRMED,"RD 2026-09-02, whole 99-image corpus: 2,172 x 72-byte and 113,356 x 84-byte index-entry values. Exactly 3 images carry BOTH, and all 3 are the corpus's UPGRADED volumes (forefst summary: APPEARS UPGRADED): win10to11refs4g and win10to11refs4g_afterwin11mount (32 x 72 B + 6 x 84 B) and win1122h2test_afteropenedwithinsider (482 x 72 B + 333 x 84 B). Every NATIVE volume carries one size only, matching its format-time version. Two controlled BEFORE/AFTER pairs prove the retention on two independent upgrade paths: win10to11refs4g_beforewin11mount (v3.4, 33 x 72 B, 0 x 84 B) -> win10to11refs4g (v3.14, 32 x 72 B + 6 x 84 B), and win1122h2test (v3.9, 482 x 72 B, 0 x 84 B) -> win1122h2test_afteropenedwithinsider (v3.14, the SAME 482 x 72 B retained + 333 x 84 B new). No tool change: forefst already tests the length range rather than the version.",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,unknown,
FS_REPS_RA_005,File System,Reparse Points,"The REPARSE_DATA_BUFFER of a DIRECTORY reparse point (junction or directory symlink) is NOT a top-level type-0xC0 row in the object's table: it lives INSIDE the object record's embedded attribute tree (E81). The object's table holds a single row keyed 0x10 whose value carries the embedded tree - typically 0xC0 (reparse), 0x90 and 0x39 - and the parent's name row is an 84-byte index entry with no room for a buffer. The embedded 0xC0 value has a 12-byte header whose u32 at +0x08 is the offset of the standard REPARSE_DATA_BUFFER (tag u32@0x00, ReparseDataLength u16@0x04, Reserved u16@0x06, then SubstituteNameOffset/Length and PrintNameOffset/Length u16 pairs; path buffer at +0x14 for SYMLINK, which carries a 4-byte Flags field, and +0x10 for MOUNT_POINT). A reader that scans only top-level rows reports these targets as absent although they are fully present on disk. A junction commonly carries PrintNameLength 0, so the SubstituteName is the authoritative fallback and the target must never degrade to the tag NAME. Same wrong-level class as E73 (attributes in a child node), so the embedded parse must be given the descent context or an object with a large attribute set is missed a second way.",raw_analysis,,3.4;3.14,2026-09,High,No,NOT_TESTED,"Not isolated to a decompiled citation. The buffer itself is the documented Windows REPARSE_DATA_BUFFER; what is established here is WHERE ReFS stores it for a directory reparse point, which the on-disk evidence below settles.",CONFIRMED,"RD 2026-09-02, whole 99-image corpus: of 341 reparse-bearing objects, 243 carry 0xC0 at the top level and 98 carry it ONLY embedded - including 78 of 81 on the real Windows volume winsider.raw. Decoding the embedded buffers yields real targets (\??\C:\ProgramData, \??\C:\Users\Default, Program Files, Common Files, Internet Explorer, Windows Defender, Microsoft Shared - the Windows compatibility junctions). NON-CIRCULAR ground truth: the lab generator writes its own CSV log onto the volume; extracting forefst_test2_log_20260705_085450.csv from win11refs8g gives the 8 reparse points it created with their intended targets. Before the fix the tool found all 8 and resolved the 6 FILE symlink targets byte-for-byte but reported NO target for the 2 DIRECTORY ones (junction1, sym_dir_abs); after it, both resolve to the generator's recorded R:\forefst_test2\reparse\rp_target_dir (the junction via its NT-namespace SubstituteName \??\R:\...). Corpus effect of the fix: 98 targets GAINED over 11 images, 0 changed, 0 lost - strictly additive.",RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
MD_DATA_RA_022,Metadata,Data Extents,"Record PLACEMENT and data RESIDENCY are independent axes (E82). A key_flags 0x02 name means the object's record was split out into a type-0x40 backing - what a move or a hard link forces - and says NOTHING about where the file's bytes live. The bytes can remain INSIDE that backing: its MAIN $DATA sub-record (single-instance marker 0x80000001 + type 0x80) is then the RESIDENT form - summary_size@0x0C=0x30, storage_type@0x10=0, byte count at +0x20, content at +0x3C. The alternative is the extent-bearing stream record (inner_hdr@0x00=0x88, summary_size 0x200 on v3.14+ / 0x1A0 on v3.4-v3.10, extents at +0x88); the two forms are MUTUALLY EXCLUSIVE. Two reader traps: an ADS is a MULTI-instance (0x80000002) 0x80 row, so matching any 0x80 row returns a stream that is not the file's data; and the backing must be joined on the PAIR (stream_idx = name value+0x00, home = name value+0x08) -> backing key (+0x08, +0x10), because stream indices are unique per home, not globally. Consequence: a reader that infers residency from key_flags reports these files non-resident and cannot recover their content, though it is in the record already held.",raw_analysis,,3.7;3.9;3.10;3.14,2026-09,High,No,CONFIRMED,"The driver's read path validates the attribute with RefsCheckValidResidentDataAttribute and reads the bytes IN PLACE at content offset 0x38 from the attribute header (= value+0x3C); it never consults a name-row placement flag, so residency is a property of the ATTRIBUTE. RefsAllocateNonResidentDataAttribute is the separate path that moves a stream out.",CONFIRMED,"RD 2026-09-02, whole 99-image corpus: 16,191 of 83,176 key_flags 0x02 files keep their data inline in the backing, over 26 images (winsider 14,580 of 72,709); mutually exclusive with the extent-bearing form (0 records carry both). Content validated on 400+ sampled files: 400/400 inline length == stated size == the name's cached size; 56/57 .xml parse as well-formed XML; 13/13 .png carry the PNG magic; 5/5 .json parse. NON-CIRCULAR ground truth: the lab generator wrote hl1_/hl2_/hl3_ hard links as exactly 400 bytes of a repeated marker (New-Marked ""HL1BODY_"" 400, corroborated by its own on-volume STATE log size=400) and the recovered bytes are BYTE-EXACT 7/7. Extends C.3a, which already recorded the phenomenon at backing+0x60 (alloc == size for small files stored resident inside the backing, 6,794/6,823 sub-cluster backings on winsider) but gave no decode for the content. Tool effect: extract/dataruns/export previously failed 'no extents decoded' on these and now read them (25/25 sampled across 3 images, 0 content mismatches); IsResident corrected on 14,118 cells over 14 images, with no other CSV column and no row count changed.",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444,yes,CONFIRMED,prior_work,3.7;3.9;3.10;3.14,unknown,
MD_SNAP_RA_008,Metadata,Stream Snapshots,"Stream snapshots are copy-on-write, so a snapshotted file's data is SHARED across its streams (E83). A block is duplicated only when it is about to be OVERWRITTEN; every block unmodified since a snapshot stays shared - present once on disk, listed in the snapshot's extent table and ABSENT from the current stream's. Consequence for the $DATA stream record: disk_alloc@0x48 is what THIS stream owns (what its own extent list covers) while total_alloc@0x30 is the FILE's whole allocation, so they diverge exactly by the shared (or sparse) blocks. Reading any version means resolving each file VCN across the streams: for the CURRENT stream a missing VCN comes from the NEWEST snapshot holding it (a block only leaves the current table while unchanged); for a PRIOR version only snapshots STRICTLY OLDER may be used, since a newer snapshot can hold content written after the version being recovered. A VCN no stream holds is a genuine sparse hole. A reader that assembles a stream from its own extents alone returns the full size with the shared blocks ZERO-FILLED - bytes present nowhere on the volume.",raw_analysis,,3.14,2026-09,High,No,NOT_TESTED,"Not isolated to a decompiled citation; the on-disk evidence is decisive on its own because the stream record's own extent-count field confirms the short extent list, and the reconstruction is validated byte-exact against independently recorded generator content.",CONFIRMED,"RD 2026-09-02. Worked case win11refs8g snapfile_03.txt: current stream 0x1000 stream_size=22688, total_alloc=24576 (6 clusters), disk_alloc=8192, extent-count field=2 covering file VCNs 4-5 ONLY; VCNs 0-2 are in snapshot 0x1001 and VCN 3 in 0x1002. Allocation-field semantics measured over 38,378 stream records: no snapshots -> total==disk on 38,286 and total>disk on 38 (sparse); snapshots present -> total>disk on 39 of 54. Defect scope: 8 distinct files (32 rows over 4 images of one lab family), 655,360 bytes silently zero-filled by extract; 0 on the real Windows volume winsider (needs refsutil streamsnapshot THEN a modification). Where the current stream owns NO clusters (snapshotted, never modified) the pre-existing CoW fallback was already correct - a 13.4 MB file extracts fully - so a first structural count of 39 files/14.1 MB overstated it. GROUND TRUTH (non-circular): the generator wrote snapfile_NN as 4096*N bytes of a marker then snapshotted and appended in a recorded sequence; after the fix 8/8 current files and 20/20 prior versions are BYTE-EXACT against that specification (versions were 8/20 before). Sparse files byte-identical, holes still zero. RD 2026-09-07 (lab314 volumes, PLAN v5 Part C): witnessed on lab314_main / _64k / _4kn (Win11 24H2, ReFS 3.14, 4 KiB / 64 KiB / 4Kn), against ground truth written on the volumes by the operator (inventory.csv 4,657+626+626 files 100% SHA-256; streams.csv per-ADS; hashes.csv; witness/hashes_t12r.csv; fsutil queryfileid). Content proof 5,908/5,909 byte-exact. T12/T12b: the step2 re-run produced snapshots `before` (12,288 B, partial CoW rewrite of the middle cluster) and `keep` (600 B, snapshotted inline file); both found, and all three T12 files byte-exact against witness/hashes_t12r.csv. E83 moves from static-only to RD. The FIRST run failed (refsutil rejected the snapshot syntax, rc=87), which is why the step1 volumes carry none.",RD,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,"format_verified 3.14 recovered 2026-09-09 from the row's own note: worked case on win11refs8g (v3.14), ""RD 2026-09-02"""
GN_TREE_RP_003,General,B+ Tree Node,"The SECOND u16 of a page-level row-index slot is a MARKER, not a counter (E84 - refutes the refsprogs-sourced GN_TREE_RP_002 'cumulative cluster count saturating at 0xFFFF'). Corpus-wide it takes exactly two values, 0xFFFF and 0, and nothing else. 0 appears ONLY on inner nodes, exactly once per page, always on the LAST slot, and always on a row with an EMPTY key (key_offset 0x10, key_size 0) whose value is a 48- or 72-byte page reference - the B+-tree's RIGHTMOST CHILD pointer (the child covering keys above every separator key). tag==0 implies an empty key with no exception; the converse does NOT hold (269 keyless rows carry 0xFFFF). The marker is written from v3.10 onward; on v3.4-v3.9 the same keyless slot carries 0xFFFF. Leaf slots never carry it. A reader must not treat the field as data: the embedded-tree parser's use of 0xFFFF as its slot-validity terminator is consistent with this, and the page-level walker correctly ignores it.",raw_analysis,,3.4;3.7;3.9;3.10;3.14,2026-09,High,No,NOT_TESTED,"Not isolated to a decompiled citation; the on-disk census is decisive because the field is exhaustively two-valued over 843,408 slots and its single non-default value coincides exactly with the keyless rightmost-child row.",CONFIRMED,"RD 2026-09-02, whole corpus: 843,408 slots -> 0xFFFF 842,529, 0 879, no other value. All 879 zeros are on inner pages, one per page, always the last slot, always a row with key_offset 0x10 / key_size 0 and a 48-byte (858) or 72-byte (21) value. tag==0 -> empty key 879/879, 0 counterexamples; converse fails on 269 keyless rows tagged 0xFFFF. Version split: v3.10/3.14/3.15/6.66 write the 0 marker (879 pages); v3.4/3.7/3.9 never do (216 pages keyless-with-0xFFFF, 0 exceptions). Of the 53 v3.14 keyless-0xFFFF pages, 48 are the three UPGRADED volumes retaining pre-upgrade pages (same write-time retention as E80) and 5 are one Container-Table (table 0x0B) inner page of 189 slots, one on each 2 TB volume. 15,642 leaf pages: 0 markers.",RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,3.4;3.7;3.9;3.10;3.14,"M3.2 2026-09-11: notes state 'whole corpus: 843,408 slots', i.e. every format in the corpus was examined. (The marker itself is only WRITTEN by v3.10+, which the description already records; the verification covered all formats.) Verified set to the claimed set."
MD_ADS_RA_002,Metadata,Named Data Streams,"A non-inline stream's EXTENT record (the type-0x0 sub-record of E61) is identified by its key SHAPE: key_offset 0x10, key_size 0x50, and attribute type 0x0003 at key+0x08 (E84 - confirms the refsprogs-sourced MD_ADS_RP_001 and sharpens it). Every such record carries a plausible stream size at value+0x38, which is the link back to the 0xB0 stream descriptor. The key itself carries NO stream name - the name is in the 0xB0 descriptor - so 'named-stream extent key' describes the record's purpose, not its key content. A reader must NOT identify the record by a zero byte at key[12]: a DIFFERENT record (14-byte key, attribute type 0x0080 at key+0x08) also satisfies that, and value+0x38 is not a stream size there.",raw_analysis,,3.4;3.7;3.9;3.10;3.14,2026-09,High,No,NOT_TESTED,"Not isolated to a decompiled citation; the discriminator is established by the exhaustive on-disk split below (key shape vs plausibility of the stream-size field), which separates the two record types with no overlap.",CONFIRMED,"RD 2026-09-02, whole corpus. key_offset==0x10 holds on 2,908/2,908 records the shipped reader resolves and 2,994/2,994 in a wider structural population. Key sizes split exactly two ways: 0x50 with type 0x0003 at key+0x08 (657 records, value+0x38 a plausible size on 657/657) and 0x0E with type 0x0080 (2,350 records, value+0x38 implausible - larger than the volume - on 2,330). Neither key form contains a decodable UTF-16 name. Tool: _stream_extent_records filtered on len(k)>12 and k[12]==0x00, which for a 14-byte key tests padding and admitted 2,382 wrong-type rows; measured impact 0 (no loose row shares a real record's stream size on any corpus image, so no ADS was ever mis-resolved). Tightened to the exact test; ads --json, files --csv and specials --json byte-identical on 297/297 corpus runs.",RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,unknown,
MD_DATA_RA_023,Metadata,Data Extents,"An extent entry's cluster number in an inline 0x10028 holder is a VIRTUAL LCN and must be validated by TRANSLATION, never by comparison against the volume's physical cluster count (E85). The virtual address space is wider than the physical one - it begins at (first_container_id << shift) and runs roughly twice as far (E74) - so a plausibility test of the form 0 < vlcn < physical_cluster_count rejects every extent that lives in the upper half of the virtual space. Because a greedy decoder stops at the first entry it cannot validate, one rejected entry makes the whole extent map decode as EMPTY and the file appears to have an undecodable/overflow holder. The correct test is whether the container table can map the VLCN; a physical bound is only a fallback where no translator is available. A sparse entry (vlcn == 0) remains valid and is zero-filled, never read.",raw_analysis,,3.14,2026-09,High,No,NOT_TESTED,Not isolated to a decompiled citation; the on-disk proof is decisive - the rejected VLCN translates cleanly through the documented container table and the clusters it names reproduce the volume's own recorded SHA-256.,CONFIRMED,"RD 2026-09-02 on win11bidule.raw (v3.14, 4 GB, 4K clusters), which ships its own SHA-256 inventory of 629 files written by the volume's operator. Worked case logs/allfiles.csv (60,490 B): holder carries 2 extents - vlcn 0x17a799 fvcn 0 run 1, vlcn 0x17a79a fvcn 1 run 14 - a contiguous 15-cluster cover equal to disk_alloc 61,440. vlcn 1,550,233 exceeds the physical count 1,044,480 and was rejected, yet translates to PLCN 731,033; reading those clusters by hand reproduces the recorded SHA-256 exactly. Effect of the correction on that volume: files matching their recorded hash go from 41 to 608 of 629 (the remaining 21 are 1 MB-791 MB files hitting the documented multi-page overflow-holder residual, all failing cleanly). No regression: extract on all 95 golden targets of the existing corpus is byte-identical and every dataruns summary is unchanged, because the correction touches content recovery rather than residency classification. Unseen until now because no image in the 99-image corpus places live file extents above the physical cluster count in virtual space.",RD,NONE,,yes,CONFIRMED,prior_work,3.14,unknown,
MD_DATA_RA_024,Metadata,Data Extents,"A file's extent map is a B+-tree NODE inside its $DATA record, not a flat run array (E86). The current stream's $DATA value carries at value+0x88 a node with the standard 0x28-byte header: level at +0x0C (0 = leaf, non-zero = index), row count at +0x14, node size at +0x20, and a trailing index array of 4-byte slots (u16 row offset, u16 key hint = the row's file VCN truncated). LEAF rows are the standard 24-byte C.4 extent entries (VLCN +0x00, file VCN +0x0C, run +0x14). INDEX rows carry the standard 48-byte four-LCN node reference; those LCNs are VIRTUAL and the child page holds the same node at 0x50 + u32@page+0x50, so the walk is uniform and recursive. NEW FIELD: record_size at +0x0A is 24 for a plain run and 24 + run*4 when the stream carries per-cluster CRC32-C (flag bit 0x80 at +0x08), the trailing u32s being those checksums, 4 bytes each. The field takes 136 distinct values (24..1048) and for checksummed records tracks the run across the full observed range (run 11->68, 66->288, 100->424, 122->512, 223->916), which a high-half-of-flags reading cannot produce. Records are 8-BYTE ALIGNED: the step to the next record is roundup8(record_size), measured on 30,524 consecutive row pairs (30,405 match; 428 genuinely padded; 119 larger gaps = unused node space, harmless because rows are addressed by the index array). This also explains WHICH files failed before: the old walk advanced '32 if u32@+0x08 == 0x1c00d0 else 24', and 0x1c00d0 is only the run==1 case, so a checksummed record with run>1 (u32 0x020000d0 at run 122) made it advance 24 and land mid-record - 19 of the 21 unreadable files on the reference volume were integrity streams. This CORRECTS C.4/C.4a: entry+0x08 is u16 flags + u16 row_size, not a u32 flags field - reading the pair as one u32 gives (row_size<<16)|flags, which is why every documented flag constant begins 0x18 (= 24, the plain row size). The $DATA row MUST be selected on the sub-stream id at key+0x10 == 0x1000: a file with snapshots carries one $DATA row per version (0x1001, 0x1002, ...) under the same key prefix, so choosing by value size or first match returns a SNAPSHOT's extents and presents that older version's bytes as the live file. Resolves the residual recorded in C.3b.",raw_analysis,,3.4;3.7;3.9;3.10;3.14,2026-09,High,No,NOT_ATTEMPTED,"Decoded from the on-disk bytes; the node header, level byte and 48-byte four-LCN child reference are the same shapes the driver's own B+-tree walk uses elsewhere (already E2-confirmed for page-level nodes).",CONFIRMED,"RD 2026-09-03. Row-size rule measured over 48,474 extent rows across 40 images: 0 violations of row_size == 24 + (flags&0x80 ? run*4 : 0); observed flag lows 0x40/0x50/0x60 (plain, row_size 24, 47,728 rows) and 0xD0 (checksummed, 746 rows). NON-CIRCULAR ground truth: win11bidule ships the operator's own SHA-256 inventory written on Windows before the image reached this project - files matching it go from 608 to 629 of 629, 0 mismatch. The 21 gained were all >1 MB (19 integrity-stream drivers, a 782 MB archive, a 791 MB ISO) and each had previously failed CLEANLY with 0 bytes; verified end-to-end through extract, including the 791 MB file. Structure present on 54 of 100 corpus images. The sub-stream selector is not cosmetic: selecting the $DATA row by size returned tests/secret.txt's 79-byte pre-truncation snapshot text as the live 25-byte file - caught by hash comparison, not assumption. Implemented as a FALLBACK ONLY (runs where the existing cascade yielded nothing), with _contiguous_cover still applied, so an incomplete walk yields no extents rather than wrong bytes and no previously-resolving file can change. Two decoder defects surfaced while validating this: tr.tr() does NOT raise on a container-table miss - it falls back to IDENTITY (VLCN read as PLCN) and counts the miss, so a direct call would accept an unmappable row and read the WRONG clusters (now tested as (vlcn >> tr.shift) in tr.map, without the counter); and because that counter is surfaced to the analyst as 'N VLCN(s) had no container mapping - output may be incomplete', probing rows that never become extents moved it (541->550 on one image with nothing incomplete). Translation is now deferred until a cover is accepted. With both fixed the whole-corpus output fingerprint (3,496 runs) shows dataruns byte-identical to the previous release on every image. Breadth of the gain, measured on the whole-corpus fingerprint: dataruns reports 48 MORE files with decoded extents across 7 images (winsider 58,127->58,144; win1122h2test x3 +7 each; win1121h2test 174->178; win11bidule 3->8; win11refs8gcompresszstddefault 103->104), 0 files lost and no existing extent list altered. Only win11bidule carries an operator SHA-256 inventory, so the other images' gains are corroborated rather than proven: all 48 gained files extract to REAL content (0 empty, 0 all-zero, 0 near-constant - the shapes a wrong physical address produces), and win1121h2test testintegrity/xbpt_tango_archive_828215.dat opens with the lab generator's own GFSAREPLAY marker. A second volume with an operator-written hash inventory is the most valuable addition to this claim's evidence.",RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,unknown,
MD_DATA_RA_025,Metadata,Data Extents,"Data residency is decided by a VOLUME-FORMAT gate, not by size alone. RefsAddAllocationForResidentWrite branches on the volume format version read from the VCB (CONCAT11(vcb[0x318],vcb[0x319]) vs 0x30b=3.11): on format <3.11 a inline write >0x20000 (128 KiB) raises 0xC0000427 STATUS_FILE_SYSTEM_LIMITATION (the v3.4 path calls RefsTelemetryUnsupportedADS, identifying it as the named-stream cap) and an already-inline stream NEVER converts; on format >=3.11 the stream stays inline only while size < 0x800 (2048 B), else RefsConvertToNonResident. Main $DATA is never created resident before format 3.11, so <=3.10 volumes are always extent-backed. Snapshot creation, enabling integrity streams, block-clone, encryption, remote/tiering, strictly-sequential and explicit set-allocation/set-EOF each convert an inline stream to extents regardless of size. The gate reads the VOLUME's format, so an upgrade affects future writes only and converts nothing retroactively.",static_analysis,,3.4;3.7;3.9;3.10;3.14,2026-09,High,No,CONFIRMED,"RefsAddAllocationForResidentWrite win11 26100 @1400ddd2c: version gate CONCAT11(vcb[0x318],vcb[0x319]) < 0x30b; error branch 0x20000 -> RefsRaiseStatusInternal(-0x3ffffbd9 = 0xC0000427), WPP trace logs 0xc0000427; residency branch 'format<0x30b || size<0x800' stays resident else RefsConvertToNonResident. win10 17134 @1c00b05a0 has NO conversion branch and calls RefsTelemetryUnsupportedADS on the >0x20000 path; RefsConvertToNonResident is ABSENT from the v3.4 driver (0 refs; 15 each in win11 26100 / 26100.8521 / Insider 29574). RefsCheckValidResidentDataAttribute exists only in the v3.14-era drivers. Complete v3.14 caller set of RefsConvertToNonResident: CreateStreamSnapshot, DuplicateExtents, AddAllocationForResidentWrite, ReplaceDataAttribute, SetEncryption, CascadesSetFileRemote, SetFileStrictlySequential, SetAllocationInfo, SetEndOfFileInfo.",CONFIRMED,"RD 2026-09-04, 523,756 rows / 117 openable paths = 79 distinct volumes (507,433 rows) (ab_census.py, path-keyed and completeness-asserted; verified by ab_verify_census.py). Format <=3.10: 7,006 rows / 18 images (v3.4,3.7,3.9,3.10) INLINE=0 and EMPTY=0, every row extent-backed, smallest 5 B holding a full 4 KiB cluster. Format >=3.11: largest inline 2,047 B, 0 of 408,670 inline rows reach 2,048 (= the driver's 0x800); that ceiling is measured on 4 KiB-cluster volumes (408,656 rows) - 64 KiB volumes contribute only 14 inline rows (max 1,685), too few to establish a ceiling there. Upgrade not retroactive: win10to11refs4g v3.4->v3.14, 0 of 262 pre-existing files changed residency; the one inline file (desktop.ini 129 B) is one of 3 names appearing only after the upgrade. Integrity: win11refs2g_setintegritystreams0 vs 1, same base volume, all 4 small files INLINE with integrity off and the same 4 EXTENT with it on.",E2+RD,E2,,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,unknown,
FS_MOVE_RA_002,Filesystem,Directory Entries,"A cross-directory move and a hard link change RECORD PLACEMENT only (key_flags 0x01 embedded -> 0x02 split into a type-0x40 backing); they do NOT change data residency. Corrects the residency wording of E70/FS_MOVE_RA_001, whose identity findings are unaffected. INFERENCE (not measured): that the split is *needed* because only the split layout carries the frozen home backref at value+0x08 is a design-intent reading - RefsMoveFile's body (win11 26100 @1400e9500, 277 lines) calls MsReparentChildTable, RefsCreateFileId2, RefsDeleteFileId2, RefsConvertToStandardInfoExternalId and RefsPersistNextFileId, and contains no reference to that offset (nor, contra E70's summary, any call to RefsAddLink/RefsRemoveLink). The OBSERVATION that the placement flips is measured; the reason is not.",raw_analysis,,3.7;3.9;3.10;3.14,2026-09,High,No,CONFIRMED,"No rename/move/link function calls RefsConvertToNonResident: 0 of 17 (win11 26100) and 0 of 18 (win10 17134) Refs*(Rename|AddLink|RemoveLink|SetLinkInfo|MoveFile|StreamRename|ReplaceLinkInDir|UpdateLink)* bodies contain a call, and the function's complete caller set contains no such function. No ConvertToResident symbol exists in any of the 4 drivers.",CONFIRMED,"RD 2026-09-04 controlled whole-volume before/after (win11refs8gtestmove_{before,after}move; both images completeness-asserted, 10,637 and 9,626 rows emitted == expected): of 9,521 files in both, 2 changed placement (hl.txt, haha2_10021.txt) plus 3 relocated (move.txt, haha2_10011.txt, haha2_10070.txt), all EMBEDDED->SPLIT, and 0 changed residency. move.txt's $DATA sub-record byte-identical before/after (76 B, sha1 ccb1c73861f55f14), inline payload BOM+'hello\r\n' at value+0x3C both sides. Independent second element: step6/win11refs8g forefst_test/hardlink_{target,alias}.txt (300 B, ground truth = generator fsactivity CREATE_HARDLINK) both A=SPLIT B=INLINE on one backing 0x74c:0x4, payload sha1 5958f030... = the bytes extract writes. Corpus: all four A x B quadrants populated on >=3.11 (SPLIT x INLINE = 14,666).",E2+RD (placement); E3/inference (the +0x08 rationale),E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.7;3.9;3.10;3.14,unknown,
MD_DATA_RA_026,Metadata,Data Extents,"READER DEFECT found 2026-09-04, FIXED in v1.10 (E89) -- this row said 'NOT fixed' through v1.10.0-v1.11.0 and is corrected 2026-09-08. A key_flags 0x02 name whose HOME object is never walked as a directory had no type-0x40 backing in walk_directory_tree's t40_content map (keyed (owner_oid, stream_idx), filled only from directories the walk visits), so resolution fell to the solo branch with rec=None and data_inline was left unset; files then reported IsResident=False although the backing's $DATA was the inline form. Content was never affected: extract resolves the backing on demand via _home_streams and returned the right bytes, labelled resident/inline. Fix applied in v1.10: the walk gained the same cached on-demand obj_map[home] lookup (_home_t40). The pre-fix join stayed reachable behind --legacy-link-join in v1.10-v1.11.0; v1.11.1 removed the flag and the old ladder, so the home lookup is the only path. Re-measured 2026-09-08 by A/B against that flag over 124 in-scope images / 568,638 files: 1,012 rows differ, every one from data_form unset to the real form -- winsider 548 to inline (reproducing E89's 548 exactly) plus 456 to extents, and 8 to extents on win11refs2tmillionsofactionsv2; SecurityId changed on all 1,012, confirming the stated blast radius. The inline symptom E89 characterised remains winsider-only.",raw_analysis,,3.14,2026-09,High,Yes,N/A,"Reader defect, not a structure claim; no driver behaviour involved.",CONFIRMED,"RD 2026-09-04, whole corpus vs an independent byte-level classifier (117 images, 523,756 comparisons, completeness-asserted): 548 name rows on step4/winsider.raw (446 distinct names, 53-2047 B, all key_flags 0x02, v3.14) report IsResident=False with data_inline unset while the backing's $DATA is the inline form. Traced on Windows/System32/spool/drivers/x64/3/MSXPSINC.GPD (parent 0x1a2e, home 0x94aa, backing (0x94aa,3), own_size 73, _backing_inline_data -> 73 B); the object's 4 other directory entries, whose homes ARE walked, all report data_inline=True. extract on that path writes the correct 73 bytes and says resident/inline. No other corpus image affected.",RD,NONE,,yes,CONFIRMED,prior_work,3.14,unknown,
MD_ADS_RA_003,Metadata,Named Data,"Named streams follow the same 0x800 (2048 B) threshold as main $DATA on format >=3.11, one-directionally: NO named stream of 2048 B or more is inline, and extent-backed ones start at exactly 2048. Below 2 KiB a stream is inline UNLESS the writer pre-allocated (alloc != size; E60), which is why 13 sub-2KiB streams are extent-backed. The documented ATTRIBUTE-FLAGS u16 at value+0x02 is the exact discriminator: bit 0x1000 set <=> content is not inline (729 extent-backed + 115 snapshot-name), clear <=> inline or empty (7,509), 0 violations. 0xB0 rows with storage_type 2 are NOT an ADS storage form: they are named SNAPSHOT entries whose value+0x44 matches an existing $DATA sub-id > 0x1000 (115/115). The 0x20000 (128 KiB) cap is an error branch that fires only on format <3.11; on v3.14 a 131,072-byte named stream stores normally.",raw_analysis,,3.7;3.9;3.10;3.14,2026-09,High,Yes,CONFIRMED,"RefsAddAllocationForResidentWrite win11 26100 @1400ddd2c: the 0x20000 raise is guarded by format <0x30b; the 0x800 branch is version-gated the same way for any inline stream. win10 17134 @1c00b05a0 reaches the 0x20000 raise via RefsTelemetryUnsupportedADS, naming the limit a NAMED-STREAM limit.",CONFIRMED,"RD 2026-09-04 ADS census over corpus manifest r2, 8,353 0xB0 rows / 57 images, 0 unrecognised; 8,238 true named streams after excluding 115 snapshot-name rows. INLINE 7,505 (max 1,920 B), EMPTY 4, EXTENT 729 (716 of them >=2048 with min exactly 2048; 13 below 2048, ALL with alloc != size: adstest 30 B/alloc 4096 and 12 SmartScreen 7 B/alloc 4096). 0 inline rows >= 2048. Attribute-flags bit 0x1000 at value+0x02 partitions inline vs non-inline with 0 violations. Format <=3.10: all named streams INLINE (285/658/928) but all <=47 B, so the 128 KiB cap is NOT exercised on disk. Name offset: key+0x10 on v3.7+, key+0x0C on v3.4 (forefst._b0_name_offset already correct; the census script had it wrong at +0x14, truncating every name by two characters - fixed, with a mutation-tested unit test).",E2+RD,E2,win10,yes,CONFIRMED,prior_work,3.7;3.9;3.10;3.14,unknown,
MD_ADS_RA_004,Metadata,Named Data,"The NAMED_DATA attribute-flags u16 at 0xB0 value+0x02 carries the named-stream residency discriminator. Bit 0x1000 is SET on every stream whose content is not inline (extent-backed streams and snapshot entries) and CLEAR on every inline stream and inline-form empty. This CORRECTS NAMED_DATA.md's parenthetical that 0x1000 'does not mean non-resident - such ADS are still inline': that reading is explained by 13 rows which look inline only if the E60 packed-allocation rule is not applied (an inline named stream stores its bytes packed, alloc == size; all 13 have alloc 4096 with size 7 or 30 and are extent-backed). Other bits observed but NOT interpreted: 0x0C00 accompanies 0x1000 on snapshot entries (giving 0x1C00, consistent with the page's existing HasSnapshot 0x0400 note), and 0x4000 accompanies 0x1000 on the 12 SmartScreen streams (giving 0x5000). Both recorded as observed, meaning not established - they are not named as flags.",raw_analysis,,3.7;3.9;3.10;3.14,2026-09,High,Yes,NOT_CONFIRMED,"No driver citation for this field yet: the residency GATE is decompiled (RefsAddAllocationForResidentWrite, MD_DATA_RA_025) but the write of this flag is not traced. SECOND ELEMENT NOT AVAILABLE IN-WORKSPACE: refsprogs source is not present (only the 2026-08-29 audit ledger, which records refsprogs deciding residency 'by attribute form' at L9-I01 but does not quote this field), so the requested independent reading could not be checked. Corroboration used instead: the E60 packed-allocation rule, which is forefst's own validated extraction path, and the internal cross-check that every 0x1C00 row is a snapshot entry independently witnessed by a matching $DATA sub-id > 0x1000 (115/115).",CONFIRMED,"RD 2026-09-04, corpus manifest r2, ADS census: 8,353 0xB0 rows over 57 images. Bit 0x1000 set on exactly 844 rows (729 extent-backed + 115 snapshot entries) and clear on exactly 7,509 (7,505 inline + 4 inline-form empty). ZERO violations of 'bit set <=> content not inline'. Observed values: 0x0000 (7,509), 0x1000 (717), 0x1C00 (115), 0x5000 (12).",RD (E2 pending: flag write not traced; refsprogs cross-read unavailable),E2,all,yes,CONFIRMED,prior_work,3.7;3.9;3.10;3.14,unknown,
FS_RESD_SA_001,Filesystem,Driver,"The size-INDEPENDENT triggers that convert an inline stream to extents are exactly the callers of RefsConvertToNonResident. Complete set in v3.14: RefsCreateStreamSnapshot (taking a stream snapshot), RefsDuplicateExtents (block clone), RefsAddAllocationForResidentWrite (a write crossing 0x800), RefsReplaceDataAttribute, RefsSetEncryption (EFS), RefsCascadesSetFileRemote (tiering/remote), RefsSetFileStrictlySequential, RefsSetAllocationInfo, RefsSetEndOfFileInfo. NO rename, move or link function is in the set - which is why a move or a hard link changes placement only (FS_MOVE_RA_002/E87).",static_analysis,,3.14,2026-09,High,No,CONFIRMED,"refs.sys win11 26100, RefsConvertToNonResident @1400e6080; caller set enumerated from every call site in the decompilation. Scanned directly: 0 of 17 (win11 26100) and 0 of 18 (win10 17134) Refs*(Rename|AddLink|RemoveLink|SetLinkInfo|MoveFile|StreamRename|ReplaceLinkInDir|UpdateLink)* function bodies contain a call. Scan control-tested against six known callers, all found.",CONFIRMED,"RD 2026-09-04: on-disk witnesses for four of the triggers. SNAPSHOT - 12 of 86 sub-2 KiB extent-backed main streams have a $DATA sub-id > 0x1000. EFS - 13 have FILE_ATTRIBUTE_ENCRYPTED. INTEGRITY - controlled pair win11refs2g_setintegritystreams0 vs 1, same base volume: all 4 small files INLINE with integrity off and the SAME 4 EXTENT with it on. FORMAT GATE - 11 were written under <=3.10 before their volume was upgraded. 44 of the 86 have no identified trigger; their composition (ETW .etl loggers, Diagnostic.log, browser-cache entries, and a uniform 128-byte generator series) is consistent with SetAllocationInfo/SetEndOfFileInfo being used before the write, but that is a HYPOTHESIS awaiting a lab test, not a finding.",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.14,unknown,
FS_RESD_SA_002,Filesystem,Driver,"RefsCheckValidResidentDataAttribute - the $DATA-SPECIFIC resident-attribute validity check - exists only in the shipping v3.14 drivers - present at 1400b9384 (26100.8115) and 1400b93dc (.8521), 81 bytes, and ABSENT from Insider 29574 as well as from v3.4 (E108). v3.4 (win10 17134) carries only the generic RefsCheckValidResidentAttribute, and no RefsConvertToNonResident at all. This is the driver-side counterpart of the on-disk fact that main $DATA is never inline before format 3.11: the older driver has neither the check for a resident DATA attribute nor any way to convert one out of line.",static_analysis,,3.4;3.14,2026-09,High,No,CONFIRMED,"Symbol census over four decompiled binaries. RefsConvertToNonResident: 0 references in win10 17134 (v3.4); 15 each in win11 26100, win11 26100.8521 and Insider 29574. RefsCheckValidResidentDataAttribute @1400b9384 present in win11 26100, absent from win10 17134. v3.4 DOES have RefsResidentWrite / RefsAddAllocationForResidentWrite / RefsAllocAndFormatResidentAttribute, so inline attributes exist there - it is resident $DATA specifically that does not.",CONFIRMED,"Consistent with the disk: format <=3.10 has 0 inline main $DATA over 5,419 rows / 14 distinct volumes, while named streams on those same volumes are all inline (285/658/928 on v3.7/3.9/3.10).",E2,E2,win11.8115;win11.8521;win11.8972;win11.9444,yes,CONFIRMED,prior_work,3.4;3.14,unknown,
GN_VCB_SA_001,General,Driver,"The driver reads the VOLUME FORMAT VERSION from the VCB as two bytes at +0x318 (major) and +0x319 (minor), combined as CONCAT11(vcb[0x318], vcb[0x319]) - i.e. (major << 8) | minor, so format 3.11 is 0x30B. This is the field every format-gated behaviour branches on, and it is the VOLUME's format, not the driver's build: an up-to-date driver mounting an older-format volume takes the older branch. Observed comparison constants in v3.14: 0x30b (3.11) and 0x309 (3.9).",static_analysis,,3.14,2026-09,High,No,CONFIRMED,"refs.sys win11 26100: RefsAddAllocationForResidentWrite @1400ddd2c reads it twice, via the SCB's VCB pointer at scb+0x90. Six occurrences of the '< 0x30b' comparison and two of '< 0x309' in that build. The values compared are real ReFS FORMAT versions (3.9, 3.11), which a driver-version field would not be.",CONFIRMED,"Behavioural confirmation on disk, without a VM: on win10to11refs4g (a v3.4 volume upgraded to v3.14) 0 of 262 pre-existing files changed residency, while the only inline file (desktop.ini, 129 B) is one of exactly 3 names that appear only AFTER the upgrade. Residency is therefore fixed at write time by the volume's then-current format, which is what a VCB-inline format field predicts.",E2+RD,E2,all,yes,CONFIRMED,prior_work,3.14,unknown,
MD_EFS_RA_006,Metadata,Sub-records,"$EFS DDF entry layout decoded. val[0x60] u32 = DDF entry count (1 on every observed record - single user, no data-recovery agent, so no DRF). The single DDF entry starts at val[0x64] with a 5-u32 header: [0x64] entry_len, [0x68] hash_len = 0x14 (SHA-1), [0x6C] wrapped-FEK length = 0x100 (RSA-2048), [0x70] FEK offset RELATIVE TO 0x64, [0x74] zero. Fixed-offset fields inside the entry: credential SID at val[0x94] (28B, S-1-5-21-...), public-key-info header at val[0xB0] (5 u32s, first = 0x14 hash length), certificate SHA-1 thumbprint at val[0xC4] (20B = 0xB0 + 0x14), container-GUID/CSP/key-container UTF-16LE strings from val[0xD8]. Two invariants hold on every record: 0x64 + entry_len == value_len - 2 and 0x64 + FEK_offset + 0x100 == value_len - 2, so the wrapped FEK is the entry's last field and the value carries 2 trailing bytes. Resolves both value sizes: FEK at val[0x1A2] on 676B records and val[0x1DA] on 732B.",page_register_gate_2026-09-05,attributes/EFS.md,3.14,3.14,High,Yes,NOT_TESTED,"Not traced in the driver: EFS metadata is produced by the EFS service/cng.sys, not by refs.sys (GN_EFS_SA_001 records the driver-side integration only). The layout is the DPAPI/EFS DDF format, decoded here on disk.",CONFIRMED,"7/7 $EFS records over 3 images (win11refs4gattributestest2 4, win11refs4gattributes 2, wininsiderrefs2t 1) satisfy all four invariants: DDF count == 1, hash_len 0x14 / FEK 0x100 / pad 0 / pk[0] 0x14, 0x64+entry_len == len-2, 0x64+FEKoff+0x100 == len-2. Both value sizes present (676B x6, 732B x1). Thumbprint at 0xC4 is constant within a certificate set and differs between them, as a per-user cert must. BREADTH CAVEAT: v3.14+ only, DDF count 1 only - no multi-user or DRA-bearing record exists in the corpus, so the count>1 and DRF-present layouts are UNVERIFIED.",RD,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
CT_COMP_RA_003,Container,Compression Parameters,"Per-volume compression parameters live in the CONTAINER TABLE ROOT PAGE header, not in a row: u32 marker at page+0xA0, u16 format at +0xA4, i16 level at +0xA6, u32 chunk size at +0xA8. The marker is VERSION-KEYED, not the constant 0x0F previously recorded (E90): 0x07 on v3.4 format, 0x0F on v3.7+. Format enum 0=None 1=LZ4 2=ZSTD 3=LZ4QAT; only 1 and 2 occur on disk. Claim is scoped to root pages that parse as an index root (descriptor thoff==0x228).",page_register_gate_2026-09-05,structures/container_table.md,3.4-3.14,"3.4,3.7,3.9,3.10,3.14,3.15",High,Yes,CONFIRMED,"Algorithm set corroborated by GN_COMP_SA_001, with the win10 side corrected: win10 17134 names FOUR CmsCompression* algorithms, not one - CmsCompressionLZX (28 occurrences), CmsCompressionLZNT1 (10), CmsCompressionXPRESS (10) and CmsCompressionXPRESS_HUFF (10). win11 26100.8115 names CmsCompressionLZ4 (13), CmsCompressionLZ4QAT (35) and CmsCompressionZSTD (19), and none of the win10 four. Function-name counts from the decompilation indexes: win11 281 ZSTD_* and 15 *LZ4* against win10 0 and 0.",CONFIRMED,"RD 2026-09-05 over 100 images: 89 carry a container-table root page, 85 parse as an index root. 0xA0 == 0x07 on 13/13 v3.4 pages (12x 4K, 1x 64K); 0x0F on 72/72 v3.7+ pages (3.7x1, 3.9x2, 3.10x2, 3.14x64, 3.15x1, +2 version-edited v3.14). No cross-over. 10 images have 0xA4 != 0: format 1 x7 / 2 x3, levels 1,3,7,9,11,13,15, chunk 0x1000/0x8000/0x20000/0x40000. OUT OF SCOPE: 4 x 2TB millionsofactions images have thoff==0x8 (not an index root) and read 0xA0=0x4004 - a different frame, not a counter-example (E49 trap). UNVERIFIED: format 3 (LZ4QAT) has no on-disk instance; the u32 at +0x98 is 0 on v3.4/v3.7 and 4 on v3.9+ except 2 v3.14 pages that read 0 - left in open_questions.",E2+RD,E2,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.7;3.9;3.10;3.14,
CT_BKRC_RA_003,Container,Block RefCount Table,"Block-refcount value is EITHER the long form - 28-byte header (0x00..0x1B, TotalRefCount at +0x18) + u16[BlockCount] per-cluster array at 0x1C..0x81B + a 4-byte field at 0x81C..0x81F, giving 0x820 (2,080 B) when BlockCount=0x400 - OR a 32-byte COMPACT form, which is the same header plus the same 4-byte trailer with the array omitted (28 + 4 = 32). E109.",page_register_gate_2026-09-05,structures/block_refcount.md,3.4-3.14,"3.4,3.14",High,Yes,NOT_TESTED,,CONFIRMED,"E109: 'exactly 0x820 (1,441/1,441)' fails on its own witness. Census over root 6: winsider 108 rows = 2,080 B x106 AND 32 B x2; win11refs5g64k 2 rows all 2,080; lab314_main 0 rows. Both 32-byte rows carry a well-formed header (key StartLCN/BlockCount mirrored at value +0x00/+0x08: 0x741800/0x400 and 0x74b800/0x800), so they are a second encoding, not damage. What the compact form MEANS is not established and is not claimed.",RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.14,
GN_PREF_RA_004,General,Page Reference,"The page-reference checksum is computed over the WHOLE referenced PAGE - the concatenation of the cluster bytes of every valid LCN slot at page-reference +0x00..+0x18, read AFTER container translation - and is compared against the value at page-reference +0x28 (length from +0x24, algorithm from +0x22). In an Object-Table row the page reference begins at value+0x20, so the LCN slots are value+0x20..0x38 and the checksum is at value+0x48. Slot count is determined by cluster size, not by version: 4 slots on 4 KiB clusters and 1 on 64 KiB, both yielding one page (16 KiB / 64 KiB). Nothing is excluded from the digest - not the page header, not the page's own self-checksum field. Where an Object Table holds several rows for one object id, only the row the reader keeps (the last) is meaningful.",page_ref_verify_2026-09-05,structures/page_references.md,3.4-3.14,"3.4,3.7,3.9,3.10,3.14,3.15",High,Yes,NOT_TESTED,"Reproduced from the bytes rather than from the driver; the pre-v3.14 verification behaviour documented on the page (CmsChecksumNone stub) is a separate, decompilation-only claim and is untouched by this row.",CONFIRMED,"RD 2026-09-05, every Object-Table page reference on 89 images: 34,311 checked, 0 skipped. The invariant is scoped to the row the READER uses: an Object Table may carry MORE THAN ONE row per object id (an earlier generation and a current one) and build_object_map keeps the LAST. On that row the digest verifies 33,883/33,883 - 89/89 images, no carve-out, no tolerance. The remaining 428 references are SUPERSEDED rows; 408 of them still verify and 20 do not, which says nothing about the volume because nothing reads them. Duplicate rows occur on 4 images only (the win11refs2tmillionsofactions family, 107 of 200 oids doubled). By cluster size: 4 slots on every 4 KiB reference, 1 on every 64 KiB one, both making one page. Both algorithms exercised: type 0x02 CRC64 and type 0x04 SHA-256.",RD,NONE,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.7;3.9;3.10;3.14,
MD_TS_RA_007,Metadata,Timestamps,"PRE_FORMAT and CHANGE_LATE are NOT independent timestomp signals - they are the two halves of ONE event, and tiering their co-occurrence as corroboration is wrong. CORRECTED 2026-09-06: the pair does NOT establish that the event was a copy. Deliberately BACKDATING a creation time produces the identical pair (create/modify set to a pre-format value, change time at the moment of the write), so the signature is AMBIGUOUS between a timestamp-preserving copy and a backdate. Witness: a lab volume whose generator log records 74 SetCreationTimeUtc actions carries exactly this signature. The INFO tier therefore means 'ambiguous - corroborate with USN', NEVER 'not suspicion': the USN journal is the only independent source that separates the two causes. A copy that preserves timestamps (robocopy /COPY:T, restore, archive extraction) writes the ORIGINAL create/modify, which predate the volume (PRE_FORMAT), and sets the change time to the copy moment, which post-dates create/modify (CHANGE_LATE). The signature a copy CANNOT produce is CHANGE_LATE WITHOUT PRE_FORMAT - created on this volume and altered afterwards; it occurs on 384 files of one real Windows volume and is the MEDIUM tier's witness set.",timestomp_base_rates_2026-09-06,tools/forefst.md,3.4-3.14,"3.4,3.7,3.9,3.10,3.14,3.15",High,Yes,CONFIRMED,"Mechanism is in the signal definitions themselves (timestomp_intrinsic_flags): CHANGE_LATE = change > max(create, modify) + margin; PRE_FORMAT = create < volume_create - margin. The tool's own docstring already noted CHANGE_LATE 'trips on a creation-time-preserving copy (robocopy /COPY:T, restore)'.",CONFIRMED,"RD 2026-09-06, base rates over the FULL corpus: 96 openable images / 521,060 files. Share of ALL files: PRE_FORMAT 118,126 = 22.67%; CHANGE_LATE 116,320 = 22.32%; CREATE_GT_MODIFY 5,410 = 1.04%; HARDLINK_MACB_MISMATCH 193 = 0.04%; ROUND_TIMESTAMPS 190 = 0.04%; FUTURE 4 = 0.00%. 23.6% of ALL files carry at least one intrinsic signal. Co-occurrence: CHANGE_LATE with PRE_FORMAT 115,936; CHANGE_LATE WITHOUT PRE_FORMAT 384 (0.33% of CHANGE_LATE), ALL on winsider.raw - a real Windows volume, the files being system components (Microsoft.UI.Xaml.winmd, DWriteCore.dll and similar) whose change time post-dates create/modify, consistent with servicing/installer metadata writes rather than tampering. So the pair is one copy signature 99.67% of the time, and the residual IS the MEDIUM cohort - created on this volume and altered afterwards, which a copy cannot produce. CONSEQUENCE: pre-1.10.1 tiering marked 22% of an ordinary volume MEDIUM-or-higher for having been copied onto it; since 1.10.1 a copy signature alone is INFO and HIGH is reserved for HARDLINK_MACB_MISMATCH (0.04%) and journal corroboration. Corpus-wide tier split after the change: HIGH 193 / MEDIUM 388 / INFO 122,348 of 122,929 flagged. PROVENANCE: an earlier draft of this row cited a 27-image subset (17.94%/12.43%/1.40%/0.31%) and stated 0 witnesses for CHANGE_LATE-without-PRE_FORMAT; that subset was lab-generated volumes only and the figure was wrong at corpus scale. PROVENANCE SPLIT (RD 2026-09-06, structural discriminator >1000 files under Windows/, NOT an xbpt_ filename heuristic which misclassifies winsider): the corpus is 1 REAL Windows install (winsider.raw, 120,617 files) + 95 LAB-built volumes (400,443 files). Flagged share: real 115,488 = 95.75% of files (HIGH 1, MEDIUM 384, LOW 0, INFO 115,103); lab 7,441 = 1.86% (HIGH 192, MEDIUM 4, LOW 0, INFO 7,245). The corpus AVERAGE of 22% therefore understates a real installed system by 4x - under the pre-1.10.1 tiering 95.4% of a real Windows volume was MEDIUM, i.e. the column flagged the operating system. Post-change the actionable set on that volume is 385 files. CAVEAT: the real-install cohort is n=1; treat the lab figures as a floor and the real figure as a single witness. UNCORROBORATED (2026-09-06): the 384 CHANGE_LATE-without-PRE_FORMAT files are the MEDIUM tier's entire witness set and they are INTRINSIC-only - no journal, hard-link or lab corroboration exists for any of them. Their reading as servicing/installer metadata writes is an INFERENCE from file identity (Microsoft.UI.Xaml.winmd, DWriteCore.dll and similar), not a measurement. They stay MEDIUM (look, not tampered) pending the T15 lab set, which must produce a known-good witness: a file created on the volume and then genuinely altered, versus one touched only by servicing, with the operator's own log as ground truth. Until then the tier rests on one volume and on reasoning, not on a controlled case. LABEL CORRECTION (2026-09-06): an earlier wording of this row and of the tool's own output called the pair a 'timestamp-preserving copy signature' and INFO 'reported, not suspicion'. That asserts a CAUSE the bytes cannot establish - a backdated creation is observationally identical - and it was contradicted by an operator generator log recording 74 SetCreationTimeUtc actions on a volume carrying the signature. The tier (INFO) is unchanged and still correct; only the claimed cause was wrong. | v1.11.0: the TimestompFlags column and the --timestomp flag were REMOVED from `files`. The regression assertion that pinned column==command is retired with them -- with one surface there is no second ladder to guard. timestomp_verdict() remains the single source for the `timestomp` command, and its unit assertions remain.",E2+RD,E2,,yes,CONFIRMED,prior_work,3.4;3.14,3.4;3.7;3.9;3.10;3.14,
GN_IMG_RA_001,General,Image acquisition,"A sparse raw image cannot distinguish a genuinely zero-filled file from a region the acquisition never captured: both read as zeros. A hole in the image file is therefore NOT evidence of missing data - a file's own zero-runs are legitimately stored as holes. The only informative case is content that is ENTIRELY zero whose WHOLE allocation lies in holes, and even that is ambiguous. Tested with SEEK_DATA/SEEK_HOLE on the image file, which is three-valued: a byte count, or undeterminable - never a silent 0.",d13_hole_detection_2026-09-06,tools/forefst.md,"n/a (image property, not on-disk)","3.4,3.14",High,Yes,NOT_TESTED,"Not a driver behaviour: this is a property of the acquisition container, not of ReFS.",CONFIRMED,"RD 2026-09-06 over 96 images / 105,889 extent-backed files. All-zero content: 18. Of those, whole allocation in image holes: 15 (0.014% of files checked); undeterminable: 0; all-zero but NOT fully holed: 3 (correctly silent). The 15 are dominated by LEGITIMATELY zero-filled files - Windows DumpStack.log.tmp, several .TMContainer*.regtrans-ms transaction containers (512 KiB and 5 MiB), and 1 MiB lab .bin files - plus the one genuine case that prompted this: xbpt_victor_tango_152379.bin on win11refs2t64ksha256checksums (505,381 bytes, a well-formed 8-cluster map, every cluster in a hole). REFUTED EN ROUTE: an earlier version warned on ANY extent overlapping a hole; measured, a 791 MB ISO, a 1-second silent WAV and 245 files with correct GFSAREPLAY content all overlap holes and all extract CORRECTLY, so overlap alone is meaningless. The tool therefore reports and never suppresses bytes: zeros may be the file's real content.",RD,NONE,,yes,CONFIRMED,prior_work,,3.4;3.14,
MD_PLAC_RA_001,Metadata,Directory entry / $DATA,"OPERATION TABLE (E87 two axes). Record placement and data residency are independent, and each operation moves at most one of them. MEASURED: create small -> embedded x inline (format >=3.11); grow past the inline ceiling -> residency inline->extents, placement unchanged; truncate to 0 -> residency STAYS extents (one-way: every driver has RefsConvertToNonResident, none has a ConvertToResident); MOVE to another directory -> placement embedded->split, residency UNCHANGED; ADD A HARD LINK -> placement embedded->split, residency UNCHANGED; rename in place -> neither changes; snapshot then read -> residency extents->snapshot-shared; write to a snapshot-shared stream -> back to extents. The two bold cases are the point: a move or a hard link relocates the RECORD and moves NO DATA.",post_thesis_analysis;raw_analysis,,3.4;3.7;3.9;3.10;3.14,2026-09,High,No,CONFIRMED,"RefsAddAllocationForResidentWrite gates residency on the VOLUME format (<0x30b); RefsConvertToNonResident exists in every examined build, no ConvertToResident.",CONFIRMED,"RD 2026-09-07: witnessed on the shipped sample volumes and generated into concepts/placement_and_residency.md by gen_residency_examples.py (gate check 9d re-runs and diffs, so an example cannot drift from the tool). All four states present: embedded x inline (WPSettings.dat, 12 B); embedded x extents (xbpt_large_149mb_alpha_610845.dat, 156,237,824 B, NEVER moved - placement does not follow size); split x extents (xbpt_log_november_496320.csv, moved); split x inline (index_data_269514.bin, 1,108 B, hard-linked - E82) incl. a 0-byte case (hardlink_sync_683343.lnk - E88); embedded x snapshot-shared (test.txt 5 B, lasttest.txt 201 B - E83). Corpus counts on win11refs2tspecials: embedded x inline 257 / embedded x extents 475 / split x inline 278 / split x extents 323.",E2,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,prior_work,3.4;3.7;3.9;3.10;3.14,unknown,
GN_IDENT_RA_001,General,Object identity,"A Windows 128-bit file id (`fsutil file queryfileid`) decomposes EXACTLY into forefst's ObjectRef: the high 64 bits are the HomeOID and the low 64 bits the FileID. Verified against an external witness on 57 of 57 objects (lab314_main), files and directories alike. A directory's file id is OID:0x0 in Windows' own reporting, confirming the v1.10.0 merge of the OID and FileRef columns. A copy takes a NEW identity (t20_src 0x707:0x3 vs t20_copy 0x707:0x2).",raw_analysis,,3.14,2026-09,High,No,NOT_TESTED,,CONFIRMED,RD 2026-09-07 T20: 57/57 exact against fsutil queryfileid captured in witness/layout.txt. (The earlier NOTE about a bare-OID ObjectRef for directories described behaviour the tool no longer has: forefst 1.13.0 prints 'OID:0x0' for 31 of 31 directories on lab314_main and a bare OID for 0 of them.),RD,NONE,,yes,CONFIRMED,prior_work,3.14,unknown,
MD_INTG_RA_005,Metadata,Integrity streams,"An integrity stream is extent-backed BELOW the 2 KiB inline ceiling: integrity overrides the residency rule. Measured on lab314_main (T19): t19_integrity/small500.bin is 500 bytes and extent-backed, where an ordinary 500-byte file on the same volume is inline.",raw_analysis,,3.14,2026-09,High,No,NOT_TESTED,,CONFIRMED,"RD 2026-09-07 T19, lab314_main.",RD,NONE,,yes,CONFIRMED,prior_work,3.14,unknown,
MD_DATA_RA_027,Content,$DATA / pre-allocation,"Pre-allocation and residency on format 3.14, with both follow-up experiments now RUN (T21, RD 2026-09-12; the row previously called them untested). (a) FileAllocationInfo DOES force extent-backing: SetFileInformationByHandle(h, 5 = FileAllocationInfo, 1 MiB) on T21/e4_allocinfo.bin leaves a 16-byte file that is EXTENT-backed - 1 extent, file_vcn 0, vlcn 603728 (plcn 259664), 1 cluster, AllocatedSize 4096, DataResidency=extents - while same-session controls of comparable size stay inline (84 B, 138 B, 16 B). (b) An edge-download ADS does NOT: T21/e6_download/5MB.zip:Zone.Identifier is 128 bytes and inline. The original T14 scoped refutation still reproduces on the same image: SetEndOfFile before any write does not force extent-backing.",raw_analysis,,3.14,2026-09,High,No,NOT_TESTED,,REFUTED,"Witness: lab314_main; xlab.ps1 lines 129-133 create both the ADS and the main stream with `fsutil file createnew`; groundtruth.txt T14 section; ADS residency read via _parse_ads_from_value (no command surfaces it -- see the label-sharing gap). What was NOT exercised: FileAllocationInformation set through SetFileInformationByHandle, and any real browser-download path. Open hypothesis recorded in open_questions.md with the two tests named.",RD,NONE,all,yes,REFUTED,prior_work,3.14,unknown,
MD_ADS_RA_005,Metadata,Named Data Streams,"A named stream on a SPLIT record is invisible to stream enumeration. `files`/`specials ads` detect ADS only from the long embedded type-0x30 value; when a move or hard link splits the record, the 0xB0 stream sub-records live in the type-0x40 backing and are never inspected. T9 (create 500 B file + 500 B ADS 's500', then move it) reports HasADS=False while the operator's streams.csv records the stream. The tool's OWN detect_ads_in_resident() returns has_ads=True names=['s500'] when handed the backing value, so the parser is correct and only the gate is wrong.",lab_T9,,3.14,3.14,High,No,N/A,"forefst.py walk_directory_tree: the ADS branch is gated on entry['is_resident'], which is False for a key_flags 0x02 index entry at enrichment time.",CONFIRMED,"T9 on lab314_main: 9/9 embedded ADS hosts reported correctly, the 1 split host missed (10 streams in ground truth, 9 reported). BREADTH: a corpus scan for type-0x40 backing records whose value the tool's own detector reports as carrying ADS finds 655 such records on 28 of 102 ReFS images. A per-name figure first quoted here (201/203/106 names) was WITHDRAWN: it joined name to backing on (parent_oid, file_id), and file_id is a PER-DIRECTORY ordinal -- on win11refs2tspecials one file_id is shared by 32 distinct backings, so that join attributes another file's streams. The join-free measurements stand: the backing-record count above, and the lab ground truth. Witness: lab314_main.raw (Win11 24H2, ReFS 3.14, 4 KiB), generated by 0906/xlab.ps1; ground truth written ON the volume (groundtruth.txt, inventory.csv, streams.csv) by the operator. | FIXED in v1.10.3: the backing tuple enumerates its own streams and the walk merges them where it already merges the EA bit; both split-record branches of the extract resolver parse streams from the backing value instead of declaring an empty list. After the fix lab314_main matches the operator's streams.csv exactly (9 hosts / 10 streams, 0 mismatches), `extract 'LAB_0906/d2/t9_adshost.bin:s500'` returns 500 bytes whose SHA-256 equals the operator's, and split rows carrying streams go 0 -> 178 (win11refs2tspecials), 0 -> 179 (win11refstestmftecmd), 0 -> 95 (win1123h2test). | The after-fix row counts (0 -> 178 / 179 / 95) come from the tool's OWN (home, file_id) resolution, the one regress assertion C1.4 covers, not from the withdrawn join.",RD,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
FS_MOVE_RA_003,File System,Move / Relocation,"The ORDER of a rename and a cross-directory move is not recoverable from the file record. T10 wrote two 500 B files: one renamed then moved, one moved then renamed. Both end as RecordPlacement=split / DataResidency=inline / ParentOID=the destination / CreationDir=the origin / IsMoved=True; the only difference is the FileId ordinal, which records creation order, not operation order. An examiner needs the change journal to separate the two sequences.",lab_T10,,3.14,3.14,High,No,N/A,,CONFIRMED,"T10 on lab314_main: t10_b.bin (rename->move) and t10_d.bin (move->rename) are identical on every reported axis; ObjectRef 0x706:0x6 vs 0x706:0x7. Neither appears in the surviving journal (see MD_USN_RA_009), so on this volume the ordering is unrecoverable from both sources. Witness: lab314_main.raw (Win11 24H2, ReFS 3.14, 4 KiB), generated by 0906/xlab.ps1; ground truth written ON the volume (groundtruth.txt, inventory.csv, streams.csv) by the operator.",RD,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
MD_SNAP_RA_009,Metadata,Stream Snapshots,"Taking a stream snapshot changes the reported data residency of an UNMODIFIED inline stream from inline to snapshot-shared. T12c snapshotted a 600-byte file -- far below the 2 KiB inline ceiling -- and left it untouched; the live stream reports DataResidency=snapshot-shared with 1 snapshot. snapshot-shared is therefore NOT exclusive to extent-backed files, and residency is not a pure function of size: the snapshot alone moves the stream to the shared form.",lab_T12c,,3.14,3.14,High,No,N/A,,CONFIRMED,"T12c on lab314_main_step2 (0907/testx2.ps1): t12_inline_kept.bin, 600 B, embedded placement, snapshot-shared residency, 1 snapshot. Extraction is byte-exact against the on-volume witness hashes_t12r.csv for all three T12 files (3/3 SHA-256). Witness: lab314_main_step2.raw.",RD,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
MD_TS_RA_008,Metadata,Timestamps,"Timestomp tiering has no discrimination on a controlled set, and the command's printed legend contradicts its own tier function. T15 built 8 files with one known cause each. Six are flagged, ALL at INFO -- 0 HIGH / 0 MEDIUM / 0 LOW over 603 flagged files. A file with all three timestamps backdated (3 signals: CHANGE_LATE|PRE_FORMAT|ROUND_TIMESTAMPS) is INFO because that set is a subset of _TS_COPY_SIGNATURE, which is correct -- a timestamp-preserving copy produces the same set -- but the legend printed above the table says 'HIGH = >=2 independent signals or 1 authoritative; MEDIUM = 1 strong intrinsic; LOW = a weak/single hint', which timestomp_verdict() never implements: HIGH comes only from an authoritative source (USN or hard-link), never from a signal count. HARD LINKS: a SetFileTime through one name updates BOTH index entries. The two type-0x30 name rows of the T15 pair are byte-identical on disk over their whole 84-byte value, timestamp block +0x10..+0x2F included, and the home backing record carries the same times. The tool prints the per-name index-entry field (value+0x10/+0x18/+0x20/+0x28), never the backing's, so the identical output is faithful to the disk and not a resolution artefact -- the per-name hard-link MACB cross-check has nothing to detect because the names genuinely agree.",lab_T15,,3.14,3.14,High,Yes,N/A,forefst.py timestomp_verdict() (the single tier source) vs the legend printed at cmd_timestomp.,CONFIRMED,"T15 on lab314_main. control.bin: not flagged (correct). copied.bin: created 1 s after modified, NOT flagged -- the copy false-positive case stays below the threshold (correct). stomp_created PRE_FORMAT; stomp_modified CREATE_GT_MODIFY; stomp_both CHANGE_LATE|PRE_FORMAT|ROUND_TIMESTAMPS; rounded.bin CREATE_GT_MODIFY only (ROUND_TIMESTAMPS needs whole-second Created AND Modified -- correct). linked.bin and linked_alias.bin BOTH show the backdated creation: the two names share one record, so a per-name hard-link cross-check cannot detect a backdate applied through either name. No USN corroboration was available because the journal had been recreated (MD_USN_RA_009). Witness: lab314_main.raw (Win11 24H2, ReFS 3.14, 4 KiB), generated by 0906/xlab.ps1; ground truth written ON the volume (groundtruth.txt, inventory.csv) by the operator. | HARD-LINK DUMP (2026-09-07): linked.bin and linked_alias.bin, both parent_oid 0x70b key_flags 0x02 value_len 84, +0x10..+0x2F = 8021ac973fd2d40109988877213edd013f8d9c77213edd0109988877213edd01 on BOTH -- created 2019-03-04 04:06:07, modified/accessed 2026-09-06 17:02:15.126631, changed .257427; whole value identical. Home backing (oid 0x70b, $SI at +0x28/+0x30/+0x38/+0x40) carries the same four times. Timestamp assignment for a key_flags 0x02 row is forefst.py:3942-3945 from the name row's own value; no post-processing overwrites it from the backing, so E89's backing resolution has NOT replaced the per-name values. | SCOPE: USN corroboration was NOT TESTABLE on this image -- T16 recreated the journal after T15 ran (MD_USN_RA_009), discarding every T1-T15 record, so every T15 verdict is intrinsic-only by construction and the absence of HIGH tiers here is not evidence that the authoritative path fails to fire. | FIXED in v1.10.3: all THREE legend sites rewritten from timestomp_verdict() -- the table header, the subcommand help text ('Tiers HIGH/MEDIUM/LOW by how many independent sources agree') and the cmd_timestomp docstring. The tier logic is unchanged; only the descriptions were wrong. MECHANISM (E112, added 2026-09-21): this measurement is of the FILE'S OWN RECORD layer and stands. The two index entries agreed because the lab's inventory pass OPENED both names; the driver refreshes only the opened name's entry, so an un-opened sibling keeps pre-stomp times. The conclusion -- no name can be called authentic -- is unchanged.",E2+RD,E2,,yes,CONFIRMED,prior_work,3.14,3.14,
MD_USN_RA_009,Metadata,Change Journal,"`fsutil usn createjournal` does not resize the ReFS journal, and it DISCARDS the existing history. T16 requested m=1048576 (1 MiB) a=262144; the volume reports Maximum Size 0x2000000 (32 MiB) and Allocation Delta 0, the same 32 MiB allocation as every other corpus volume. The intended wrap therefore never happened -- only 3.1 MB of the 32 MiB window is used -- yet no record of any operation performed before the call survives. FORENSIC SIGNAL: a journal whose USN range starts at 0 on a volume with substantial prior activity indicates the journal was recreated, not that the volume is young; a genuinely rolling journal starts at a non-zero First Usn.",lab_T16,,3.14,3.14,High,No,N/A,,CONFIRMED,"T16 on lab314_main: allocation 33,554,432 B (8192 clusters), USN range 0 - 3,146,304, 32,004 records, 8,646 distinct names. Names from T16 onward are present (56,000 f_*.bin mentions, plus t18/t19); no T1-T15 name appears. CONTRAST: winsider, same 32 MiB allocation, USN range 40,906,752 - 74,459,840 -- a span of exactly one allocation, i.e. a full rolling window with a non-zero start. Witness: lab314_main.raw (Win11 24H2, ReFS 3.14, 4 KiB), generated by 0906/xlab.ps1; ground truth written ON the volume (groundtruth.txt, inventory.csv) by the operator.",RD,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
MD_SF_RA_005,Metadata,Sparse Files,"A sparse region is unallocated, and the allocated-versus-logical ratio is the on-disk signal. T18 wrote 65,536 bytes, then `fsutil sparse setflag` + `setrange 4096 57344`. The file reports logical 65,536 with 8,192 bytes allocated -- 2 clusters backing a 16-cluster file -- attributes Archive|SparseFile, placement embedded, residency extents. Extraction is byte-exact and the hole reads as zeros.",lab_T18,,3.14,3.14,High,No,N/A,,CONFIRMED,"T18 on lab314_main: extracted 65,536 B, SHA-256 matches the operator inventory exactly. Region 0-4,096 has 4,080 non-zero bytes, region 4,096-61,440 has 0, region 61,440-65,536 has 4,080 -- the two written ranges intact and the punched range zero. Witness: lab314_main.raw (Win11 24H2, ReFS 3.14, 4 KiB), generated by 0906/xlab.ps1; ground truth written ON the volume (groundtruth.txt, inventory.csv) by the operator.",RD,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
MD_DEL_RA_004,Metadata,Deletion,"Deletion recovery is correctly keyed to DATA residency, not record placement -- but a remnant whose declared inline region reads as zeros was still reported as 'FULL FILE recoverable ... EXACT' and yielded a zero-filled file. Those zeros have TWO explanations -- the file held zeros, or the deletion took the bytes -- and nothing in the remnant separates them, so the outcome names both rather than asserting either. T17 deleted one file per class. Correct: del_inline (500 B inline) -> full content; del_split (500 B, MOVED then deleted, so a split record whose data stayed inline) -> full content, which is the E87 two-axes rule holding through deletion; del_extent and del_snap -> metadata only; recycle_me -> metadata + carve. DEFECT: the residency verdict is taken from the remnant's value LENGTH, not from whether the value actually carries the bytes. del_split's slack row carries a 1,336-byte value with only 104 non-zero bytes and no data pattern, so `export deleted` wrote 500 zero bytes and the manifest labelled them confidence=high, recoverable_inline, EXACT.",lab_T17,,3.14,3.14,High,Yes,N/A,"forefst.py deleted/export-deleted: the recoverable_inline verdict keys on value_len, with no check that the value's data region is populated.",CONFIRMED,"T17 on lab314_main: all 5 deletions land in the DELETED section (the tool correctly separates 233 DELETED from 1,026 STILL PRESENT, so a live file's stale slack row is never presented as a deletion). Proof the zeros are fabricated rather than real content: every T16 f_*.bin was written with the same 300 non-zero bytes ('REFSLAB-T16-300 ' + a byte ramp); of 849 recovered, 635 carry that pattern and **214 are 300 zero bytes**. Reading the two T17 rows through the tool's own page reader confirms the disk: del_inline's 1,336-byte value has 602 non-zero bytes and the pattern at +348, del_split's has 104 non-zero and no pattern (an earlier 623/108 pair came from reading ONE cluster of a multi-cluster page and is superseded; the conclusion is unchanged) -- the tool read the disk faithfully and mislabelled the result. BREADTH of zero-filled 'recovered' content: lab314_main 228/877, winsider 6,110/8,459, win11refs8g 57/72, win11refstestmftecmd 11/15, win11refs2tspecials 0/2. Witness: lab314_main.raw + the on-volume groundtruth.txt. | FIXED in v1.10.3: `recoverable_inline` now requires the remnant to HOLD the bytes; a surviving descriptor whose declared inline region is zeroed grades `content_zero_or_absent` -- 'content zero or absent (indistinguishable in the remnant)', reliability NO CONTENT and `export deleted` writes no content file for it. Re-measured after the fix -- content files written / all-zero among them, before -> after: lab314_main 877/228 -> 649/0, winsider 8,459/6,110 -> 2,349/0, win11refs8g 72/57 -> 15/0, win11refstestmftecmd 15/11 -> 4/0, win11refs2tspecials 2/0 -> 2/0. The count withheld equals the previous all-zero count on every image, so no populated content was lost. FALSE-NEGATIVE COST, measured: a genuinely zero-filled resident file is graded content_zero_or_absent too -- 1 of 4,037 live resident files on lab314_main, 1 of 33,263 on winsider, 0 of 4 on win11refs2tspecials.",RD,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
MD_TS_RA_009,Metadata,Timestamps,"The MLog is a timestomp corroboration source where the change journal is not. A backdated $SI write leaves NO MLog transaction of its own -- the log records the file's creating transaction, not the SetFileTime -- but that CREATE carries an EMBEDDED timestamp, and comparing it with $SI Created convicts a backdate from an independent structure. On lab314_main the journal had been destroyed by the T16 createjournal call, so the MLog was the only corroboration available, and it caught exactly the two files whose creation was backdated and no others. SCOPE: this corroborates the BIRTH time only. A file whose LastWrite was stomped but whose creation was untouched agrees with its CREATE record and is correctly not flagged by this comparison. Coverage is partial and ages out: the MLog is a circular buffer, so a CREATE record exists only while it has not been overwritten.",lab_T15,,3.14,3.14,High,Yes,N/A,,CONFIRMED,"RE-MEASURED 2026-09-19 under the driver's framing (E97). MECHANISM AND ALL FOUR T15 WITNESSES REPRODUCE TO THE MILLISECOND: control.bin 17:02:14.435 vs $SI 17:02:14 AGREE; stomp_created.bin 17:02:14.583 vs 2019-03-04 04:06:07 CONTRADICTS; stomp_both.bin 17:02:14.936 vs 2019-03-04 04:06:07 CONTRADICTS; stomp_modified.bin 17:02:14.778 vs 17:02:14 AGREE. COUNTS RESTATED -- mlog --parse on lab314_main now reports 460 CREATE, 5,173 WRITE, 3,833 DELETE (previously 2,846 CREATE / 1,002 DELETE / 1,829 ENTRY_REMOVE). CREATE FALLS because a truncated transaction showed only its opening INSERTs and was classified as a creation; the old parse over-reported file creation about six-fold. WORDING: the corroborating transaction is labelled WRITE, not CREATE -- its opcode sequence (INSERT_ROW INSERT_ROW SET_OBJECT UPDATE_DATA_WITH UPDATE_ROW DELETE_ROW INSERT_ROW ...) both creates the name and writes the data.",RD,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
MD_SNAP_RA_010,Metadata,Stream Snapshots,"A stream snapshot does NOT keep a copy of the file's $SI timestamps. The 116-byte snapshot descriptor carries exactly one FILETIME, at descriptor+0x4C, and it is the moment the SNAPSHOT was taken -- not a frozen copy of any $SI field. Its position relative to the live $SI therefore reconstructs the operation order, and it is an independent witness against a stomped $SI: a creation time ABOVE the snapshot timestamp is impossible and therefore a contradiction between two structures. The reverse is not: a file must exist before it can be snapshotted, so C < snapshot ts is the NORMAL ordering and backdating only moves C further below it. Measured on lab314_main_step3, 3 of 3 snapshotted files show C < snapshot ts - including the deliberately backdated p07_snapshot_then_backdate.bin (C = 2023-09-12 17:02:57, snapshot 2026-09-12 17:03:17) and the row's own two untouched witnesses t12_cow.bin and t12_inline_kept.bin. The test catches FORWARD-dating, not backdating.",lab_T12,,3.14,3.14,High,No,N/A,,CONFIRMED,"lab314_main_step2, dir OID 0x721. t12_cow.bin (written, snapshotted 'before', then the middle cluster rewritten): snapshot ts 11:57:31.792 sits BETWEEN live $SI C=11:57:31.730 and M=11:57:31.832 -- the create/snapshot/modify order exactly. t12_inline_kept.bin (written, snapshotted 'keep', never touched): snapshot ts 11:57:32.077 is AFTER C=32.045 and M=32.047. Neither descriptor contains any other FILETIME-shaped value (scanned every 4-byte offset), so no $SI copy is present. t12_small.bin, snapshotted while inline then grown past the 2 KiB ceiling, carries NO snapshot sub-record at all -- the snapshot did not survive the transition to extent-backed. The +0x4C layout was already documented on attributes/SNAPSHOT.md; what is measured here is the behaviour.",RD,NONE,,yes,CONFIRMED,prior_work,3.14,3.14,
MD_CS_RA_003,Metadata,Case Sensitivity,"Corpus census of the per-directory case-sensitivity flag ($SI internal_flags bit 0x02, MD_CS_RA_001): 12 flagged directories over 2 of 102 readable images, and only 2 of those directories actually hold a pair of names differing only by case. On win11bidule 11 of the 12 are one directory subtree (tests/testdir), the flag being inherited by subdirectories created inside a flagged directory. The colliding pair is the only configuration in which a case-folded path resolver can return the wrong record (E94): with a single spelling present a folded match returns the correct row anyway.",raw_disk,,3.14,3.14,High,No,CONFIRMED,"Flag semantics are E2 (RefsSetCaseSensitiveInfo / RefsQueryCaseSensitiveInfo, win11_4b0558f6); the census itself is raw-disk over the corpus",CONFIRMED,"census_case_sensitive_dirs.py over corpus.lst 2026-09-10: 102 readable images, 12 flagged dirs on win11bidule (11, tests/testdir subtree) and win11refs4gattributestest2 (1); colliding pairs = win11bidule tests/testdir HI.txt/hi.txt and win11refs4gattributestest2 newtests/firstdir/testcasesensitive WindowsCaseSensitive.txt/windowsCaseSensitive.txt. Both pairs verified against ground truth the project did not produce; see E94. Guarded by verify_claim.py --regress assertion 29 (FAILS on the pre-fix resolver, 3 counter-examples).",E2+RD,E2,win11.8115;win11.8521;win11.8972;win11.9444;insider,yes,CONFIRMED,this_project,3.14,3.14,E94; census 2026-09-10; cites MD_CS_RA_001/MD_CS_RA_002/MD_DISK_RA_009
MD_DATA_RA_028,Metadata,Data Extents,"Holder-form census of extent-backed streams (102 images, 109,588 streams, 0 unattributed). Three decode paths produce every map, and their shares depend on the ORDER the dispatcher tries them. Measured through the shipped dispatcher (_decode_holder_extents, 'ORDER (1.12.0)': structural/E86 first, then the embedded index array, then the contiguous 0xA8 sub-record array) over 117 readable images and 261,339 extent-backed streams: structural/E86 259,033 (99.1%), embedded index array 2,251 (0.9%), contiguous 0xA8 array 0 (0.0%), 55 unattributed. The earlier 54.4% / 37.1% / 8.5% split was taken with a different precedence and does not describe what the tool does now - a share here is a property of the order, not of the volume, so any figure must name the order it was measured under.",raw_disk,,3.4;3.7;3.9;3.10;3.14,3.4;3.7;3.9;3.10;3.14,High,No,N/A,Census of this project's own decode paths; no driver claim is made,CONFIRMED,"holder_form_census.py over corpus.lst 2026-09-11, read-only (decoders wrapped, not modified): 102 images, 109,588 extent-backed streams, every one attributed to the decoder that produced its map, 0 unattributed. Branch split inside _find_extents_in_subrecord measured separately over 133,145 accepted sub-record decodes. Report: analysis/reports/M2_1_holder_form_census.md",RD,RD,,yes,CONFIRMED,this_project,3.4;3.7;3.9;3.10;3.14,3.4;3.7;3.9;3.10;3.14,M2.1 census 2026-09-11; supersedes the estimated 18% structural share with a measured 37.1%
MD_DATA_RA_029,Metadata,Data Extents,"The field documented as valid data length in the MI $DATA sub-record header is at value+0x40 (v3.4: +0x44) - NOT +0x28, which is the SI $DATA (resident) table's field and is UNMEASURED. At +0x40 it EQUALS stream_size on every non-empty record in the corpus: 75,112 of 75,112 across v3.7/3.9/3.10/3.14, and is never GREATER (0 of 76,328), which is what a wrong offset would produce. No record has VDL < stream_size. That holds even for generator files written as a short marker then extended with SetLength, whose tails ARE holes in the image: either ReFS zero-fills on extension, or the field is not a valid-data-length. VDL SEMANTICS ON ReFS ARE THEREFORE UNCONFIRMED, and no behaviour may be keyed on the field until lab item T22 decides it (write 10 bytes, SetLength 1 MiB, fsutil file queryvaliddata, image, read the descriptor). v3.4 is unmeasured: its stream records are not exposed as MI $DATA sub-records with inner header 0x88, so the documented +0x44 is untested.",raw_disk,,3.7;3.9;3.10;3.14,3.7;3.9;3.10;3.14,High,Yes,N/A,Driver writes VDL via RefsWriteFileSizes (MD_FTBL_007); no new static work here,CONFIRMED,"vdl_census.py over corpus.lst 2026-09-11: 102 images, 76,328 MI $DATA stream records; VDL == stream_size 75,112, stream_size == 0 on 1,216, VDL > stream_size 0, VDL < stream_size 0. v3.4 contributed 0 records (predicate never matched). Report: analysis/reports/M2_3_vdl.md | Offset corrected 2026-09-12: the census measured MI $DATA +0x40; plan v7.4 B3 cited +0x28, which belongs to the SI $DATA (resident) table - a different structure, still unmeasured. The equality holds on files whose tails are holes, which is why the semantics, not just the offset, are the open question.",RD,RD,all,yes,CONFIRMED,this_project,3.7;3.9;3.10;3.14,3.7;3.9;3.10;3.14,"M2.3 census 2026-09-11; upgrades structure_reference's VDL row from NEW (no notes) to measured, and scopes it away from v3.4 | v7.4 B3: recorded as a knowledge finding rather than filed as 'no test'; T22 is the decider"
MD_DATA_RA_030,Metadata,Data Extents,"Extent-map decoder order: the two STRUCTURAL readings (nested B+-tree node via its index array, E86; plain holder at fixed stride from a validated descriptor) must be consulted before the heuristic marker scan that matches a 4-byte constant. Through forefst v1.11.3 the scan was consulted first and could answer with a wrong single run of the right length, which the accept-guard cannot distinguish from the right one: 23 streams over 11 distinct files decoded to the wrong clusters, 9 of them to cluster 0 (the volume boot record). Fixed in v1.12.0; erratum E95.",raw_disk,,3.7;3.9;3.10;3.14,3.7;3.9;3.10;3.14,High,No,N/A,Decoder-order defect in this project's own tool; no driver claim is made,CONFIRMED,"Corpus A/B against the PUBLISHED v1.11.3, 2026-09-11, re-derived by running both shipped tools side by side: 102 readable ReFS volumes of 106 corpus entries; 23 records over 11 distinct files changed clusters (9 files to VLCN 0, 1 built on 0x000E0080, 1 unindexed row), every one with different bytes; the unit here is the FILE: v1.11.3 maps 109,567 files and v1.12.0 maps 110,160; the M2.1 census's 109,588 counts extent-backed STREAMS over the same corpus and is a different unit. Witnesses: 9 boot-sector files read \\x00\\x00\\x00ReFS (43 non-zero bytes of 16,384) under the old map and real content (~16,318) under the new; the 0x000E0080 file extracted 505,381 zero bytes under the old map and begins GFSAREPLAY, the generator's own marker, under the new. The millionsofactions record is content-proven (M3.4, 2026-09-11): the old map's cluster VLCN 0x6732e74 / PLCN 0x338ae74 is byte-identical to cluster 91 of a DIFFERENT live file (xbpt_sierra_victor_918254.bin, 470,384 B, 4 extents), and each candidate cluster is referenced exactly once on the volume. Secondary effect: 593 more FILES gain a decoded extent map, of which 152 are byte-proven (generator content marker) and 441 unproven (real non-zero content, no independent record; refscat corroborates 3 of 49 tested on one 4K volume, 0 disagreements) (unit = file; dataruns lists one entry per file and no sub-streams, so this is not comparable with an earlier stream-level 641 from an artefact that was not kept). Corpus-wide re-derivation 2026-09-11 ran both shipped tools over all 106 corpus entries: 102 readable, 4 refused (2 NTFS, 1 NTFS variant, 1 BitLocker); 109,567 files mapped by v1.11.3 and 110,160 by v1.12.0.",RD,RD,,yes,CONFIRMED,this_project,3.7;3.9;3.10;3.14,3.7;3.9;3.10;3.14,M2.2 decoder order 2026-09-11; content proof added by M3.4 2026-09-11 (E95)
FS_VBR_RA_014,Filesystem,VBR,"A boot-sector version LOWER than the volume's true format is SILENTLY REWRITTEN UPWARD AT MOUNT, and the self-checksum recomputed, so downward VBR version tampering ERASES ITSELF. RefsUpgradeVersionInBootSector (called from RefsMountVolume) compares boot+0x28/+0x29 against _VCB::GetVolumeUpgradeVersion and overwrites the pair only when the stored version is STRICTLY LESS (major < target, or major == target and minor < target); it then recomputes the ROR1+ADD self-checksum at +0x16 and calls RefsWriteBootSector, restoring both on write failure. Measured on the win11refsmini version-edit series, with the limits of that evidence stated: NO image in the corpus reads 3.12 (141 ReFS volumes scan as 3.4 x13, 3.7 x1, 3.9 x2, 3.10 x2, 3.14 x120, 3.15 x1, 6.66 x2), and all three VBR copies of both '...rechangedtoversion312' images read 3.14 / sha8 6759cfa5. The corpus holds only the POST-mount capture, so the bytes cannot distinguish 'edited to 3.12 then rewritten' from 'never edited' - the 3.12 step rests on the image's file name and the operator's account, not on a pre-mount witness. (The two images that were never mounted, 6.66_opened and 3.15, differ from the base in exactly one region, the boot sector, by 4 and 2 bytes.) An implausible version (6.66) is NOT rewritten and does not mount: the image is byte-identical before and after the open attempt and the checkpoint clock does not move (vclock 64). A version ABOVE the driver's own maximum was never mount-tested, so its behaviour is unmeasured. FORENSIC CONSEQUENCE: a VBR version consistent with the volume's structures does NOT prove the field was never altered -- one mount launders a downward edit, and the only trace is ordinary metadata churn. This QUALIFIES FS_VBR_RA_013: primary/backup divergence exposes UPWARD or invalid tampering (6.66, 3.15 survive untouched against an authentic 3.14 backup), but not a downward edit that has since been mounted. BACKUP COPY (resolved 2026-09-13): RefsWriteBootSector writes the backup LBA and then LBA 0, so a mount-time correction normally rewrites BOTH copies and leaves no primary/backup divergence for an examiner to find -- the erasure is complete, not partial. A device-object condition can reduce it to the primary alone. The format-UPGRADE path does not call this routine, which is why a genuine upgrade still leaves the pre-upgrade version in the backup (FS_VBR_RA_013).",v3.0.5_research,,3.14,3.14,High,Yes,CONFIRMED,"win11latest_c02d29ed (26100.8521): RefsUpgradeVersionInBootSector @14028fedc, sole caller RefsMountVolume; strict-less-than guard on boot+0x28/+0x29 vs _VCB::GetVolumeUpgradeVersion, then a checksum recompute and a write. CORRECTION (K142): the format-UPGRADE path DOES reach RefsWriteBootSector, so the claim that it does not is refuted. RefsWriteBootSector @14009afb0 has exactly two call sites - inside RefsUpgradeVersionInBootSector (L428474) and inside RefsReadWriteBootSector (L485818); the same 2+1 grep pattern holds in 8115, 8972 and 9444. RefsReadWriteBootSector @1402e6ddc is a 48-byte dispatcher: mode '\x03' reads, anything else writes. RefsMarkVolumeForUpgrade @140256a10 reads with mode 3, sets boot+0x2c |= 0x80 when bit 7 is clear, recomputes the ROR1+ADD checksum into +0x16, and writes with mode 4 - and mode 4 is a WRITE. So an upgrade does rewrite the boot sector; whatever leaves the pre-upgrade version in the backup copy, it is not the absence of this call.",CONFIRMED,"RD. analysis/rawdisk/disks/step4continuing/win11refsmini_* version-edit series. A full 512-byte-aligned signature scan finds exactly THREE 'ReFS\0\0\0\0' copies per image: 0x1000000 (primary, at the partition start), 0x3110000, and 0x7cfffe00. The DRIVER's backup is the third, not the second: RefsWriteBootSector sets the target LBA to VCB+0x1f0 - 1, and InitializeVcbFromBootSector @1402e80ec assigns VCB+0x1f0 from the boot sector's TotalSectors at +0x18; here TotalSectors = 0x3e0000 with 512-byte sectors, so the backup LBA is 0x3dffff = image offset 0x1000000 + 0x3dffff*512 = 0x7cfffe00. The copy at 0x3110000 is partition-relative LCN 0x2110 and sits in the BitLocker (FVE) metadata reservation - 'FVE-EOW' at 0x3122000 and 'OLRDHEVF' at 0x3124000 follow it. The OBSERVATION is unaffected: both candidate copies read 3.14, sha8 6759cfa5, on all 15 images including the 6.66, 3.15 and 3.12-named edits.",,E2+RD,3.14,yes,CONFIRMED,this_project,3.14,3.14,E96 investigation 2026-09-13
FS_OTBL_RA_009,File System,Object Table,"Object Table value+0x18 is a 64-bit LOG SEQUENCE NUMBER, not a generation counter: u32[6] (value+0x18) = offset within a log segment, u32[7] (value+0x1C) = segment number. It records the log position at which that object was last modified, in the same address space as the checkpoint LSN at CHKP+0x70. Supersedes the 'generation counter = checkpoint virtual clock' reading (E104).",raw_analysis,,all,3.4;3.7;3.9;3.10;3.14,High,No,NOT_TESTED,"The writer was not decompiled; the reading rests on a controlled disk experiment with a null control plus exact agreement with the checkpoint LSN, not on driver code.",NEW,"LAB-G, 3 images of ONE volume: labG_0 creates dirA/dirB/dirC (f0..f4 each); labG_1 modifies one file in dirA ONLY; labG_2 modifies one file in dirB ONLY; dirC is never touched after creation (null control). dirA 0xa000008dd -> 0xb000008f1 -> unchanged; dirB unchanged -> unchanged -> 0xc00000906; dirC frozen on all three. 6/6 transitions as predicted, control never moved. CORROBORATION 15/15 volumes: max(u64 at value+0x18) == the active checkpoint's own LSN at CHKP+0x70 EXACTLY on the 3 LAB-G images and 12 randomly sampled corpus volumes (4K and 64K clusters, v3.4-v3.14, 2 GB to 2 TB, incl. one 4Kn) -- expected when the object table is written last at checkpoint time. REFUTES 'u32[6] = checkpoint virtual clock': the field takes 8-50 distinct values per volume (a clock has one) and on labG_0 the clock is 4020 while the field ranges 0..19907. Forensic use: orders object modifications in LOG time, independent of $SI timestamps an attacker can set, and identifies objects modified after a given checkpoint. No tool surfaces it yet.",RD,RD,,yes,CONFIRMED,this_project,3.4;3.7;3.9;3.10;3.14,3.4;3.7;3.9;3.10;3.14,
FS_CHKP_RA_012,File System,Checkpoint,"CLEAN-DISMOUNT INVARIANT: on a cleanly dismounted volume the checkpoint is the last structure written, so max(Object-Table value+0x18 LSN) == CHKP+0x70 exactly. A volume torn away mid-work leaves objects carrying log positions BEYOND the checkpoint, and max(OT LSN) > CHKP+0x70. This is the only surface that separates an uncleanly dismounted volume from a recovered one - the CHKP flag word is identical (0x682) on both.",raw_analysis,,all,3.14,High,No,NOT_TESTED,"Not decompiled; the reading rests on a controlled before/after pair plus a whole-corpus census, not on driver code.",NEW,"LAB-F: the same volume imaged before an unclean detach (labFbeforereboot, vclock 3986), after Windows recovered it (labFafterreboot, 4002), and before the lab (labBeforeF, 3975). CHKP+0x70 vs max OT+0x18: baseline (7,0x166)==(7,0x166) EQUAL; UNCLEAN (8,0x109e) vs (8,0x4b2f) AHEAD by 0x3a91; recovered (9,0x8a2)==(9,0x8a2) EQUAL - so the signal tracks the dismount, not the lab. CENSUS over the whole corpus: 117 ReFS images measured, exactly ONE ahead (labFbeforereboot), 0 false positives. Both copies of the checkpoint carry flags 0x682 on the dirty and the recovered image alike, which is why no flag-based test can work. Free to compute: build_object_map already walks every OT row in every bootstrap. Builds on E104 (value+0x18 is a per-object LSN).",RD,RD,,yes,CONFIRMED,this_project,3.14,3.14,