File systems

Disks, partitions, and volumes got you to a mounted volume — a logical range of addressable storage. This chapter is about what turns that raw space into something meaningful: files, directories, permissions, timestamps — the actual file system.

The file system as an interpreter

A volume, on its own, is just a sequence of addressable blocks. The file system driver is what interprets specific on-disk structures within that space and presents them, through the same I/O Manager machinery every other kind of I/O uses, as directories, files, and their associated metadata. NTFS — the primary general-purpose Windows file system — organizes this around a central structure, the MFT (Master File Table), which records an entry for essentially every file and directory on the volume: its name, its attributes, and where its actual data lives.

Journaling: surviving an interrupted write

Modifying file-system metadata is inherently a multi-step operation — updating the MFT, adjusting free-space bookkeeping, updating directory entries — and a power failure or crash partway through those steps could, without care, leave the file system in an inconsistent, even unusable state. NTFS addresses this with journaling: before making a metadata change, it first records the intent of that change in a separate log. If the system crashes mid-operation, the file system can replay the journal on next mount and either complete or cleanly roll back whatever was interrupted, rather than being left in an undefined intermediate state. This is a direct, practical reason NTFS volumes recover cleanly from unexpected power loss far more often than older, non-journaled file systems did.

Deleting a file is a namespace operation, not necessarily a data-erasure one

A detail with real practical consequences, including for anyone doing forensic or data-recovery work: deleting a file through the ordinary Windows delete operation generally removes its namespace reference (its directory entry, and marks its MFT entry as available for reuse) — it does not necessarily overwrite the actual data blocks that file occupied. Until those blocks happen to be reused by some later write, the original content can often still be recovered by tools that read the volume directly rather than through the ordinary namespace. This is exactly why "securely delete" or "wipe" tools exist as a distinct category from ordinary file deletion — they exist specifically to overwrite the underlying data, something the standard delete path was never designed to do.

A worked example: why "empty the Recycle Bin" doesn't mean "unrecoverable"

Even after a file is deleted and its Recycle Bin entry is cleared, the underlying data blocks may remain physically present and readable on the volume for an indeterminate period afterward — right up until ordinary disk activity happens to allocate those specific blocks to some new file's data. This is a frequently-surprising, genuinely consequential fact for anyone reasoning about data disposal on a machine that's about to be repurposed, resold, or discarded — the file system's namespace-level "delete" and an actual, verifiable data erasure are two different operations with two different guarantees.

A common mistake

Assuming file deletion is equivalent to secure data destruction is one of the most consequential misunderstandings in this entire course — not because it's an obscure internals detail, but because acting on the wrong assumption has real, sometimes serious, practical consequences (data ending up recoverable on discarded or resold hardware). The file system's job is to manage the namespace and metadata efficiently; erasing the underlying bytes promptly on delete would actually work against that efficiency goal (it's slower, and unnecessary for ordinary use), which is exactly why it was never the default behavior.

Where this connects

• The Cache Manager works closely with the file system to keep frequently-accessed metadata and data fast to reach without repeated disk I/O.
• Reparse points & symlinks covers a file-system-level mechanism for redirecting a path somewhere other than its literal on-disk location.