How recovery differs on NTFS, FAT32 and exFAT

The short version

None of this changes the fundamental rule — the data is only recoverable until something writes over it — but it explains why two people with identically deleted files get results that look nothing alike.

NTFS: the file system that remembers most

NTFS keeps one record per file in the Master File Table. The record holds the name, a reference to the parent folder, the timestamps, and the run list — the complete map of which stretches of the disk hold the file, in order. Deleting clears a flag in the record's header and frees the file's clusters in the volume bitmap. The record itself, run list and all, is left in place until something needs that slot.

Three consequences follow, and together they make NTFS the most recoverable of the three.

• Fragmented files come back correctly. The run list survives, so a file scattered across twenty places on the disk is read back in the right order. When a file is so fragmented that its run list will not fit in one record, NTFS keeps the rest in extension records — a reader that stops at the base record reports a whole file as a shred of one, so those have to be followed too.
• Very small files come back perfectly or not at all. A file below roughly a kilobyte is stored inside its own record, with no clusters anywhere. If the record is readable, the file is complete.
• The journals can undo the reuse of a record. The change journal keeps names, parent folders and times for files whose records have already been given away. The transaction log holds what NTFS would need to put a freed record back — which is the whole record, run list included. That is the difference between knowing a file existed and being able to read it.

Two NTFS features complicate a naïve reader and are worth knowing about, because a tool that ignores them silently gives you rubbish: compressed files store their clusters as compression units rather than as their own bytes, so the data has to be decompressed rather than copied; and the file table has a mirror, plus a backup boot sector in the last sector of the volume, both of which matter when the originals will not read.

FAT32: the name survives, the map does not

FAT32 has two structures: directory entries, holding the name, the size and the first cluster of each file, and the File Allocation Table, a chain that says for each cluster which cluster comes next. Deleting a file writes a marker over the first character of its name in the directory entry, and clears its entries in the allocation table.

That second part is the whole story of FAT32 recovery. Once the chain is gone, the only facts left are where the file started and how long it was. If the file was written in one continuous stretch — which most photographs on a camera card are, because a camera fills a card front to back — reading forward from the first cluster returns the file exactly. If the file was fragmented, there is no record anywhere of where the other pieces went, and no software can reconstruct it from the file system.

So on FAT32 a good tool reads forward from the first cluster and checks, cluster by cluster, whether the space is still free. Free and continuous means the file is whole; a stretch that has been taken by something else means the file comes back partly. That is a measured statement rather than a guess, and it is what the survival bar in a recovery list is drawn from.

The missing first character of the name is the other visible artefact. It cannot be recovered — it was overwritten by the delete marker — so an honest tool shows a placeholder rather than inventing a letter. A recovered _MG_4471.JPG was almost certainly IMG_4471.JPG, but the file system no longer says so.

exFAT: it depends on whether the file was in one piece

exFAT is what cards larger than 32 GB and most modern cameras use. Its directory entries are richer than FAT32's: each file is described by a set of entries holding the full name — no character is overwritten on delete — the length, the first cluster, and a flag saying whether the file was stored contiguously.

That flag is the useful part. When it is set, the file never had a chain at all: its clusters run straight on from the first, and the entire file is known precisely from the deleted entry. Recovery of such a file is exact, not inferred. When it is not set, the file was fragmented and its chain has to be followed as far as it still reads.

In practice this makes exFAT cards recover very well, because the way cameras write — one large file at a time onto mostly empty space — produces contiguous files almost all of the time.

ext4, XFS and the ones Windows will not mount

Disks out of a NAS, a Linux machine or an Android device are usually ext4 or XFS, and Windows offers to format them rather than read them. Unlost reads ext2, ext3, ext4 and XFS directly, along with the ext journal, and can find volumes inside an LVM container.

Deletion on ext is harder to undo than on NTFS, and it is worth saying plainly: ext4 clears more of a file's addressing information when it deletes than NTFS does, so name-and-contents recovery is less reliable there even though the data itself is just as present. The journal recovers some of it; the rest comes back by content, without names.

APFS, HFS+, btrfs, ReFS, ZFS and UDF have no reader in Unlost. What it does instead is name them when it finds them, because "this disk holds an APFS volume" is a fact you can act on, and "this disk appears to be empty" is how a healthy disk gets thrown away.

How to tell which file system you have

If the drive still mounts, right-click it in Explorer and choose Properties; the file system is on the first tab. If it does not mount, you cannot check this way and it does not matter — recovery software identifies the volume by reading its boot sector rather than by asking Windows, which is exactly why it can read drives Windows has given up on.

As a rule of thumb: internal Windows drives and most large external hard drives are NTFS; memory cards of 32 GB and under and small USB sticks are FAT32; cards above 32 GB and cards formatted by a modern camera are exFAT.

Questions about file systems and recovery

Which file system gives the best chance of recovery?

NTFS, by a clear margin, because it keeps the map of a file's pieces and two journals that remember deletions. But the file system matters far less than what has been written to the drive since — a quiet exFAT card beats a busy NTFS system drive every time.

Should I format my memory card as exFAT or FAT32?

Use whatever your camera recommends, which for anything modern is exFAT. Formatting a card in the camera rather than on a computer is the safer habit, because the camera writes the layout it expects.

Why did my recovered file names come back with a missing letter?

That is FAT32. The delete marker is written over the first character of the name, so it is genuinely gone from the disk. A tool that fills it in is guessing at something it cannot know.

Why does a large video recover worse than a photo?

Because size and fragmentation go together. A photograph usually fits in one continuous stretch; an hour of video may not, and on FAT32 the map of where its pieces went is cleared by the delete. On NTFS the same video usually recovers fine, because the run list survives.

Does converting a drive between file systems affect old deleted files?

Formatting to a different file system writes a new index over the old one and leaves the data alone, so previously deleted files are no more or less recoverable than before — but the tool now has to find them by their contents rather than through an index. Recovering files after a quick format covers what that looks like.