Supported File Systems

Supported File Systems

FAT12/16/32 only, for filesystem-aware recovery (byterescue/recovery/filesystem.py, used by the "Recover by File System" mode) — it parses the real boot sector/BPB, walks directories recursively (short 8.3 and VFAT long-filename entries), and recovers deleted entries whose data hasn't been overwritten yet. NTFS and exFAT are not implemented: selecting that mode against one reports a clear "not a recognizable FAT12/16/32 volume" error rather than silently finding nothing.

Outside of that one mode, ByteRescue still only ever does two filesystem-agnostic things:

1. Reads ordinary files/folders through normal Windows file APIs — which works on whatever filesystem Windows itself mounted, because that's Windows doing its job, not ByteRescue implementing filesystem support.
2. Carves raw bytes out of a file or device path (signature/text modes), which never looks at directory entries, an MFT, or a FAT allocation table at all.

Fragmented deleted files (FAT limitation)

Even within FAT12/16/32, filesystem-mode recovery has a real limitation worth understanding: deleting a file on FAT erases that file's cluster chain in the FAT table (not just the directory entry), so a deleted file's later clusters are usually already gone even when its name/size/start-cluster survive.

ByteRescue therefore assumes contiguous allocation for a deleted file spanning more than one cluster — the same approach classic FAT-undelete tools use, and the same reason they've always struggled with fragmented deleted files. Every such result is labeled with this assumption and marked lower confidence; a deleted file that fits in a single cluster needs no such assumption and is marked High confidence.

Physical drive listing vs. physical drive scanning

The Storage Devices list uses WMI/CIM (Get-CimInstance Win32_DiskDrive) for metadata only — model, capacity, interface, status. No raw sector access happens there.

Physical-drive scanning (Deep / Raw Scan mode, or choosing "Physical Drive" as a source) opens the raw device path (\\.\PhysicalDriveN) directly, which needs Administrator privileges and has not been verified against real hardware in this build — it is real code, not a stub, but treat it as unverified until you've tried it on a real device; if it fails to open the device it will report a read error rather than do anything unsafe.

Important limitations

• SSD TRIM: Modern SSDs use TRIM, which can make deleted data unrecoverable. The Recovery Center shows a warning when the selected physical drive reports as SSD/NVMe (via Get-PhysicalDisk's MediaType, which is more reliable for this than Win32_DiskDrive). ByteRescue cannot bypass TRIM — nothing can, once the underlying flash has actually been erased.
• Encrypted drives: BitLocker or other encryption must be unlocked first; ByteRescue does not decrypt anything.
• RAID arrays: Not supported — no RAID metadata parsing or member reconstruction exists.
• Write-protected media: Read-only physical write protection is a property of the device itself, not something ByteRescue manages.

See also Recovery Center for how "Recover by File System" fits alongside the other three recovery modes, and FAQ for "when recovery isn't possible."