-
-
Notifications
You must be signed in to change notification settings - Fork 1
FAQ
No. ByteRescue is intentionally conservative about recovery claims — it does not guarantee recovery of every file type, filesystem, or deleted file. Signature and text-pattern carving are best-effort methods; a match is not a guarantee of a complete, undamaged file. See Recovery Signatures for what each format's "verified" vs. "unverified" actually means.
Not yet for filesystem-aware recovery ("Recover by File System" mode) — only FAT12/16/32 is implemented. Selecting that mode against an NTFS/exFAT volume reports a clear error instead of silently finding nothing. The other three recovery modes (signature, text, deep/raw scan) work on raw bytes regardless of filesystem, since they never read a filesystem's own metadata. See Supported File Systems.
No — and nothing else can either, once the underlying flash has actually been erased by TRIM. This is a hardware/firmware-level limitation, not something any recovery software can work around.
No. It's a read-oriented tool. Analysis and the Hex Viewer are strictly read-only, and recovered files are always written to a separate destination you choose — never back to the source. The Recovery Center warns you if your chosen destination is on the same physical drive as the source.
Not as-is. ByteRescue does read-only analysis but does not currently implement forensic-grade acquisition (hashed imaging, chain-of-custody tracking, write-blocking enforcement). For legal cases, consult a digital forensics professional.
No — there's no RAID metadata parsing or member reconstruction. Complex RAID configurations need specialized tools.
FAT deletes a file's cluster chain from the FAT table, not just its directory entry, so a deleted file's later clusters are often already gone even when its name/size/start-cluster survive. ByteRescue assumes contiguous allocation for multi-cluster deleted files (the same approach classic FAT-undelete tools use) and labels every such result as an assumption with lower confidence. Single-cluster files need no such assumption and are marked High confidence. See Supported File Systems.
Verified means the recovered item's end offset was proven from the format's own structure (an exact length field, a checksummed footer, or a fully walked container/section table). Unverified means no reliable end marker exists for that format, so a size cap was used instead — treat it as a guess. See the full breakdown in Recovery Signatures.
No. Every recovered item also gets a separate structural validation pass (Passed / Partial / Failed /
Unknown) using a real parser for its format (Pillow, zipfile, sqlite3, wave, gzip decompression).
A signature match alone is never reported as a successful recovery.
Windows only, currently. Linux and macOS support is listed as a future consideration in Contributing.
Getting Started
Recovery
Help
Developers