Concepts
How ReFS works — the mechanisms behind the on-disk format, grouped from orientation to deep internals.
New to ReFS? Start with General — NTFS vs ReFS, Version Detection,
and Version Evolution give you the lay of the land.
For a forensic investigation the load-bearing concepts are the bootstrap and addressing model
(Bootstrap Chain, Virtual Addressing), the copy-on-write
update policy that makes history recoverable (Copy-on-Write), and the recovery and
timeline techniques (Deletion Recovery, Timestomping Detection,
What Survives).
General
| NTFS vs ReFS Comparison | NTFS vs ReFS Comparison# Almost every ReFS forensic mistake is really an NTFS habit applied to the wrong file system. NTFS is a flat Master File Table updated in place, … |
| Version Detection | Version Detection# A ReFS volume’s version is a parsing precondition, not a label you can read once and set aside. Many structures change layout, size, or behaviour … |
| Version Evolution | Version Evolution# ReFS is not one format but a family of closely related ones, and the differences between them decide whether a parser reads a volume correctly or … |
| Driver Interface | Driver Interface# The on-disk structures only tell half the story; the other half is the code that writes them. This page is the static-analysis companion to the Driver … |
On-disk mechanics
| Bootstrap Chain | Bootstrap Chain# Before a ReFS parser can read a single file, a directory, or any B+-tree, it has to find the trees in the first place — and there is exactly one path … |
| ReFS Driver Architecture | ReFS Driver Architecture# The single most useful fact for anyone parsing ReFS is that the driver is built in two layers, and only the lower one ever touches the disk. The … |
| Virtual Addressing | Virtual Addressing# Virtual addressing is the rule that decides where ReFS data actually lives on disk, and it is the first thing a tool built for NTFS gets wrong. A … |
| Cluster and Page Size | Cluster and Page Size# The cluster size is a single number chosen when a ReFS volume is formatted, and it quietly sets the geometry of almost everything else on disk: how … |
| Resident vs Non-Resident Storage | Resident vs Non-Resident Storage# The single most consequential question a ReFS recovery tool can get wrong is where a file’s bytes actually are. ReFS stores file … |
| Copy-on-Write (CoW) | Copy-on-Write (CoW)# Copy-on-write is the rule that makes ReFS recoverable: no metadata page is ever overwritten in place. Every modification writes a new copy of the … |
| Space Allocation and Free-Space Management | Space Allocation and Free-Space Management# ReFS decides which clusters are free and which are in use with a three-tier bitmap allocator (Medium, Container, Small), all … |
| Transactional Crash-Consistency | Transactional Crash-Consistency# ReFS keeps its metadata consistent across power loss with two cooperating mechanisms: a redo-only metadata log (MLog) that records … |
Integrity & redundancy
| Checksum Architecture | Checksum Architecture# ReFS protects its metadata with a Merkle-tree variant: every B+-tree parent stores a checksum of each child page, so corruption is caught the … |
| Integrity Streams | Integrity Streams# An integrity stream is a per-file, opt-in feature that protects a file’s data with per-block checksums, so the driver can detect — and, on a … |
| Volume Redundancy — Boot Sector, Superblock, Checkpoint copies | Volume Redundancy — Boot Sector, Superblock, Checkpoint copies# Every ReFS volume keeps redundant copies of the three structures it needs to mount — the boot sector, the … |
Files, metadata & features
| Object IDs and FileIds — the Cross-Table Join Key | Object IDs and FileIds — the Cross-Table Join Key# Every persistent ReFS object — file, directory, or system table — carries a 64-bit Object ID (OID) that the Object … |
| OID Allocation — Monotonic Counter and Deletion Estimation | OID Allocation — Monotonic Counter and Deletion Estimation# Every persistent ReFS object draws its 64-bit Object ID (OID) from a single per-volume counter that only ever … |
| Attributes | Attributes# In NTFS every piece of a file — its name, its timestamps, its data, its security — is an attribute, and a parser that knows how to walk the attribute list can … |
| Hard Links | Hard Links# A hard link is a second (or third, …) directory name that points at one physical file. On ReFS the mechanism is unusual enough that a parser written … |
| Stream Snapshots and File Versioning | Stream Snapshots and File Versioning# A ReFS stream snapshot freezes a file’s current content under a new stream identity, so that later writes leave the … |
| WSL / Linux Metadata on ReFS | WSL / Linux Metadata on ReFS# When the Windows Subsystem for Linux (WSL) accesses a ReFS volume through a DrvFs mount with -o metadata, it persists Linux ownership, … |
| Compression | Compression# ReFS compression is the feature most likely to make a file’s bytes on disk look like noise to a naive parser, and it is invisible to every standard … |
| Deduplication | Deduplication# Deduplication is the one ReFS feature that deliberately stores file content with no live file pointing at it. It is an opt-in, post-process feature … |
| Tiered Storage and the Heat Engine | Tiered Storage and the Heat Engine# A ReFS volume can silently relocate file data between a fast tier (NVMe/SSD) and a slow tier (HDD), and can compress, decompress, or … |
Forensics & recovery
| Deletion Recovery | Deletion Recovery# When a file is deleted on ReFS, the question for an analyst is not whether an entry was scrubbed in place — ReFS rarely overwrites anything — but where … |
| What Survives: Artifact-vs-Event Survival Matrix | What Survives: Artifact-vs-Event Survival Matrix# On a ReFS volume the analyst’s first question is rarely how is this structure laid out — it is given what happened … |
| Timestomping Detection | Timestomping Detection# Timestomping — back-dating a file’s timestamps to hide when it was really created or written — is a standard anti-forensic move, and the … |
| Timestamp Sources and the Super-Timeline | Timestamp Sources and the Super-Timeline# Time is the spine of most filesystem investigations, and ReFS scatters it across five independent artifacts that an analyst has … |
| Forensic Analysis Workflow | Forensic Analysis Workflow# This is the end-to-end runbook for examining a ReFS volume: a fixed, ordered triage that takes an analyst from “is this even … |
| Tool-to-Artifact Map | Tool-to-Artifact Map# This page is the bridge between the question in your head and the byte layout that answers it. For each forensic goal — recover deleted names, find … |
Background & context
| File Systems | File Systems# Every ReFS forensic decision rests on a small number of general file-system ideas — what a cluster is, how files point at their data, how the namespace … |
| Windows File Systems | Windows File Systems# Before a single ReFS byte is ever read off disk, the volume has already passed through half a dozen Windows kernel layers, and an analyst who does … |
| Carrier's Five Data Categories Applied to ReFS | Carrier’s Five Data Categories Applied to ReFS# Brian Carrier’s File System Forensic Analysis organises every file-system artifact into five reference … |