Reference
What Unlost can read
Two different lists answer two different questions, and they get confused constantly. The file systems list is what decides whether your files come back with their names and folders. The file types list only applies when there is no file system left to read — after a format, or on a card whose directory area is unreadable — and the deep pass has to recognise files by their contents instead. A file type missing from the second list is not a file that cannot be recovered. It is a file that cannot be recognised by its bytes alone.
File systems
When the file system is readable, Unlost recovers files of any type, with the names, folders and dates the file system kept. There is no format restriction on this path at all.
| File system | Where you meet it | What is read |
|---|---|---|
| NTFS | Windows internal drives, most external hard drives | The Master File Table including free records, folder indexes read exhaustively, the free-space bitmap, files stored inside their own record, NTFS-compressed data, and both journals |
| exFAT | Large SD cards, modern USB sticks, cards over 32 GB | The directory entry sets including deleted ones, cluster chains where they survive, and the allocation bitmap |
| FAT32 | Camera cards, USB sticks, older devices | Directory entries including deleted ones, long file names, cluster chains, and the allocation table |
| FAT16 and FAT12 | Small and old cards, embedded devices | The same as FAT32 |
| ext4 | Linux systems, NAS boxes, Android internal storage | Inodes with both extent trees and the older indirect-block addressing, directory blocks, the block bitmap, data stored inside the inode, and the jbd2 journal |
| ext3 and ext2 | Older Linux systems and NAS disks | The same as ext4, using the indirect-block addressing those versions use |
| XFS | Enterprise Linux, some NAS boxes | Allocation groups, inode B+trees, directory blocks, and the free-space trees used to tell whether a deleted file's blocks have been handed out again |
Damaged volumes get more than the primary structures. NTFS has a backup boot sector in the volume's last sector and a mirror of the start of its table; ext keeps superblock copies scattered through the volume, one of which is enough to reconstruct both the geometry and where the volume itself begins; XFS repeats its superblock in every allocation group. All of those are read when the primary will not, which is the direct answer to "the disk is not initialized".
Which of them keep a journal
A journal is what lets a file come back that the current file table has completely forgotten — the section on journals explains why. Not every file system has one.
| File system | Journal | What it adds |
|---|---|---|
| NTFS | $LogFile and $UsnJrnl | Names for files whose records were reused, the day a delete happened, previous names after a rename, and — from the transaction log's undo images — complete records with their run lists, so a file can come back whole rather than merely named |
| ext2, ext3, ext4 | jbd2 | The copy of the inode as it stood before the delete emptied it, which restores the addresses ext4 discards on truncate |
| XFS | Not read | XFS deletion rewrites the inode and zeroes its size and extent count, so a deleted XFS file usually comes back as a name and a date only |
| FAT32, exFAT, FAT16, FAT12 | None exists | These file systems keep no journal at all, which is why the contiguity assumption described in the FAT section matters so much there |
One limitation worth stating plainly: an ext volume can be configured with its journal on a different device. Unlost detects that, names it, and shows the journal's identifier so you can match the two devices — but it cannot reach across to a device that is not in front of it.
Partition layouts and containers
| Layout | Support |
|---|---|
| MBR partition tables | Read, including the chain of extended and logical partitions |
| GPT partition tables | Read, with the checksums verified, plus the second complete copy at the far end of the disk — which is what makes a destroyed table survivable |
| No usable partition table | The medium is swept sector by sector for the start of a file system, and a hit is believed only once the structures behind it parse and agree. This is what finds a partition nothing has recorded |
| Linux LVM | Read from the LVM metadata, including the metadata history — which is the only thing on the disk that still says where a logical volume that has since been removed used to be. A logical volume with extents on a disk that is not present is reported as incomplete rather than stitched together with zeros |
| 4K native drives | Sector size is determined from the medium rather than assumed, because a table read in the wrong units puts every partition at the wrong address |
| Disk images | An image made by Unlost, or a plain sector-by-sector .img, is scanned exactly like a drive. Where Unlost made the image, the log of unreadable areas beside it is used to flag affected files as damaged when they are found |
| BitLocker volumes | Recognised, not decrypted — including BitLocker To Go, which hides behind a working FAT32 boot record. Unlost reports the encryption method, the available unlock methods and the recovery key identifier, and refuses to carve encrypted noise |
| RAID arrays | Not reassembled. Member disks can be imaged and scanned individually, but Unlost does not reconstruct a stripe set |
Recognised, but not read
These file systems are identified and named when they turn up, and then Unlost tells you it cannot read them. Being told "this is an APFS volume from a Mac and this program cannot read it" is worth something; a search that comes back holding nothing is a disk somebody throws away.
- APFS — what a Mac uses today.
- HFS+ — what a Mac used before APFS.
- btrfs — a Linux file system common on NAS boxes.
- ReFS — Microsoft's server file system.
- ZFS — used on storage servers and some NAS boxes.
- UDF — optical discs and some large removable media.
A volume of one of these types can still be scanned with the deep pass, which does not care what file system the bytes are laid out under — it will find files by their contents, without names. That is a real fallback, but it is a much worse outcome than a proper read.
The 64 file types the deep pass recognises
This list matters only when there is no file table left to read. Files found this way come back as numbered names with the right extension, without folders or dates, because the name, the folder and the dates lived in the file table and the file table is what is gone. Where a format states its own length, that length is read; where it does not, the file is capped and the name carries _partial so a guess is never presented as a measurement.
Photos and images — 21
Eleven of these are camera raw formats, because photographs are what people most often arrive here having lost.
jpg · png · gif · bmp · tif · webp · heic · avif · psd · psb · arw (Sony) · cr2 and cr3 (Canon) · dng · nef (Nikon) · orf (Olympus) · pef (Pentax) · raf (Fujifilm) · rw2 (Panasonic) · srw (Samsung) · x3f (Sigma)
Video — 10
mp4 · mov · m4v · mkv · webm · avi · wmv · 3gp · ts · m2ts
Documents — 18
pdf · doc · docx · xls · xlsx · ppt · pptx · odt · ods · odp · rtf · epub · msg · pst · chm · ics · vcf · sqlite
Audio — 8
mp3 · m4a · aac · flac · ogg · wav · wma · aiff
Archives — 7
zip · 7z · rar · tar · gz · bz2 · iso
What this list cannot do for you
A carved file is recovered only while it is contiguous on the medium. A header and the bytes after it are all a signature scan can see, so a fragmented file needs a run list, and a run list exists only in a file table or a journal. This is why the file systems list above is the one that decides how well a recovery goes, and this list is the last resort.
Which recovered files can be checked afterwards
Every recovered file is checked against its own format, and the check gives one of three answers rather than two, because the formats are not equal at answering. The reasoning behind the third answer is worth reading if you are recovering camera raw files.
| Strength of check | Formats | What a clean result means |
|---|---|---|
| Arithmetic | png; zip and everything built on it — docx, xlsx, pptx and their macro-enabled variants | Every byte is covered by a stored checksum. A single changed byte anywhere fails it. This is the strongest statement available |
| Structural | jpg; gif; pdf; the ISO base media family — mp4, m4v, m4a, mov, heic, heif, avif, cr3, 3gp; and the old Office container — doc, xls, ppt, msg | The file is a complete one of its kind: the structure closes and every internal offset lands inside the file. It is not proof that the contents are the right contents, and it is reported as the weaker answer it is |
| None possible | Bare mp3, and every TIFF-based camera raw — arw, cr2, nef, orf, pef, raf, rw2, srw, dng and the rest — along with everything else not listed above | The format carries nothing to check against. Unlost says so and tells you to open the file, rather than reporting it intact because nothing disagreed |
A format check never overrules what the scan already knew. If clusters were known to be missing before the file was opened, the file is reported broken with the reason the scan gave — a photograph whose middle was overwritten can still walk cleanly from marker to marker.
Unlost is a Windows application. This download is a Windows installer, and it won't run on the device you're reading this on.
Free · Windows 10 and 11, 64-bit · 4.0 MB installer · a scan only reads, so it costs you nothing to find out