Concepts

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 forms a graph, and how a file system stays consistent across a…

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 not know that path can misread what refs.sys actually controls and what…

Brian Carrier's File System Forensic Analysis organises every file-system artifact into five reference categories — File System, Content, Metadata, File Name, and Application. The value of that model for an analyst is…

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, with a redo and undo journal; ReFS is a forest of per-object B+-trees…

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 across versions — the page reference shrinks from 104 to 48 bytes…

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 silently misreads it. Across six known versions — v3.4 (Windows 10 1803)…

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 upper layer speaks Windows filesystem semantics — files, names…

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 Architecture model — it reads the refs.sys binary across three…

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 that gets it there. Every address on the volume is a virtual cluster…

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 number found in a file's extent table or in a B+-tree root is a…

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 many clusters fit in a container, the stride of the virtual-to-physical…

The single most consequential question a ReFS recovery tool can get wrong is where a file's bytes actually are. ReFS stores file content in one of two modes, chosen per file: resident content lives inline, packed into…

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 affected page and propagates the pointer change up the B+-tree to a fresh…

ReFS decides which clusters are free and which are in use with a three-tier bitmap allocator (Medium, Container, Small), all sharing schema 0xe010. For a forensic analyst this allocator is the authority that separates…

ReFS keeps its metadata consistent across power loss with two cooperating mechanisms: a redo-only metadata log (MLog) that records committed transactions, and a dual checkpoint whose alternating flush is the atomic…

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 moment the child is read by recomputing the checksum and comparing it to the…

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 mirror or parity storage space, repair — silent corruption or out-of-band…

Every ReFS volume keeps redundant copies of the three structures it needs to mount — the boot sector, the superblock, and the checkpoint — but it does not maintain them the same way, and that difference is what makes…

Every persistent ReFS directory or system table carries a 64-bit Object ID (OID). The Object Table maps that OID to the object's own B+-tree, so the OID is the handle by which the whole filesystem refers to a directory…

A ReFS file has no Object ID of its own (that identifier belongs to directories and system tables — see Object IDs). A file is instead identified by a FileId: the pair

Every persistent ReFS directory and system object draws its 64-bit Object ID (OID) from a single per-volume counter that only ever moves forward. Files are not allocated an OID — a new file instead takes the next…

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 read the whole file. ReFS keeps the same vocabulary…

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 for NTFS will get the link count wrong every time: there is no…

A ReFS stream snapshot freezes a file's current content under a new stream identity, so that later writes leave the snapshotted bytes intact and exactly recoverable from a single disk image. For a forensic analyst this…

When the Windows Subsystem for Linux (WSL) accesses a ReFS volume through a DrvFs mount with -o metadata, it persists Linux ownership, permission, and special-file identity directly on disk. It does this with two…

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 Windows tool. There is no compression flag on a file, an extent, or a…

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 (Enable-DedupVolume) that lets a single physical block back many…

A ReFS volume can silently relocate file data between a fast tier (NVMe/SSD) and a slow tier (HDD), and can compress, decompress, or recompress that data, based on how often it is accessed — all with no user action and…

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 the prior bytes still live and for how long. Because copy-on-write…

On a ReFS volume the analyst's first question is rarely how is this structure laid out — it is given what happened to this disk, which artifacts can I still recover, and by what method? This page answers that directly.…

Timestomping — back-dating a file's timestamps to hide when it was really created or written — is a standard anti-forensic move, and the technique an analyst reaches for first does not exist on ReFS. NTFS exposes it by…

Time is the spine of most filesystem investigations, and ReFS scatters it across five independent artifacts that an analyst has to read separately and then reconcile: the per-file $SI MACB times, the USN change journal…

This is the end-to-end runbook for examining a ReFS volume: a fixed, ordered triage that takes an analyst from "is this even ReFS?" through version/state classification, structural bootstrap, live-file enumeration…

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 the change journal, prove a timestamp was forged — it names the…

Two different things get called "making a file non-resident", and they are decided by different code in the driver. This page lists the functions that actually change a file's storage, what each one changes, which…

ReFS answers two questions about every file, and they are independent. Almost every mistake made about ReFS storage — including several made by this project and corrected in its own errata — comes from treating them as…