Recuva deep scan files won’t open: check the size, then the header

Part of our guide on fix android update app issues

A 4 KB photo where a 4 MB one should be is not a dead file. It is a carver that stopped early.

Why Recuva deep scan files won't open after the carve

Say you recovered a folder of photos and half of them open to grey squares or a strip of colour. The files are there, the names look wrong, and nothing in the tool told you they were damaged. That is the deep-scan trade-off showing up after the fact.

A normal scan reads the file system: it finds the file name, its size, and the list of clusters where the data lives. Deep scan skips all of that. It reads raw sectors, watches for the byte patterns that mark the start of a known file type, and copies forward until it hits the pattern for the next file.

That method is why deep scan recovers anything at all when the file table is destroyed. It is also why the results are guesses. The tool has no idea where the file really ends, so it stops at the next signature, a size cap, or the end of readable data. Any of those three can cut a file in half.

• No file name: deep scan never reads the directory entry, so you get numbers instead.
• No real size: the size is whatever the carver guessed before it stopped.
• No cluster chain: fragmented files come out in the wrong order or partial.
• No verification: the tool reports a file as recovered even when the data under it was overwritten.

What the size test tells you before you open anything

Picture opening the folder, sorting by size and seeing a row of 4 KB files where your photos should be. That single column answers more than any second scan will. A photo that should be several megabytes and comes out at 4 KB was cut off almost immediately after its header. People in this spot often ask about pdf converter keeps selectable text as well.

Ignore the exact figure and use the order of magnitude. A phone JPEG is single-digit megabytes, an MP3 is under a few megabytes per minute, a text document is tens to hundreds of kilobytes. Compression and camera settings decide the real number, so you only need the right magnitude.

Find the expected size from a thumbnail preview in your photo app, file-size history from a backup folder, or the original file still sitting in a cloud sync directory. If none of those exist, compare the recovered file to similar files you still have.

A file at exactly 0 bytes means the carver found the signature and copied nothing. That is the worst reading, and it usually means the sectors held nothing readable under that signature. We go through checking system limits for affinity photo step by step elsewhere on the site.

The header test: read the first bytes, not the file name

Say you open a recovered JPG in a viewer and get an error, so you assume the file is dead. Open it in a hex viewer instead and the first bytes often still read FF D8 FF. The start of the file survived even though the end did not.

Every common format starts with a known signature. JPEG begins FF D8 FF, PNG begins 89 50 4E 47, PDF begins 25 50 44 46, a ZIP-based Office file begins 50 4B, MP4 has ftyp a few bytes in. If those bytes match, the header was carved correctly.

The quick version needs no hex tool. Copy the file, rename the copy with the right extension, and try to open it. An image viewer that shows a partial image, a top strip or a grey block has read the header fine. A viewer that refuses outright, or shows noise from the first pixel, is looking at scrambled bytes. The other half of this decision is best windows controls for parents.

A guessed extension can send a viewer down the wrong decoder. A raw camera file carved and labelled as .jpg may open fine once renamed to .cr2 or .nef, because the tool picked the wrong signature family. If a file won't open under its guessed name, try one or two other plausible extensions.

1. Copy the suspicious file to your recovery drive so you never touch the original.
2. Open the copy in a hex viewer or a viewer that shows raw bytes.
3. Compare the first 4-12 bytes to the known signature for that format.
4. If the signature matches, note the size gap and move to a second carver.
5. If the signature is wrong or missing, mark the file as overwritten and stop.

A second carver for truncated files, and when to stop

Suppose your size test says several megabytes expected, 40 KB recovered, and the header reads FF D8 FF. That is the best possible bad news: the data is still on disk and the carver simply stopped early. A tool that follows fragmentation instead of stopping at the next signature can finish the job.

PhotoRec ignores the file system entirely and carves by signature like Recuva, but it tries harder to follow a file across fragmented clusters. Run it with file_enable set to the formats you need and paranoid_bf set to 0 for speed. DMDE shows you the raw clusters and lets you rebuild a file by hand, which is slower but recovers files the automatic carvers miss. Windows File Recovery from Microsoft does signature carving and a mode that reads the file table when it still exists. Run it with the /extensive switch for deep scan and /segment to carve NTFS fragments. The other half of this decision is video converter app producing low bitrate at 1080p.

Set expectations honestly. None of these tools can recover a file whose sectors have been overwritten, and none can reconstruct data that was never fully written. A carver that handles fragmentation well will rescue truncated files and leave the rest exactly where Recuva left them.

A single second-pass carve costs 20 to 90 minutes per 100 GB depending on the tool and drive speed. That is time lost if the header test already told you the sectors are overwritten. Run each tool once and accept the result.

How to tell the file was overwritten before you started

Say the drive was in daily use for a week after the deletion, with Windows updates and browser tabs. The sectors your file occupied were being reused the whole time, and the carver is reading whatever replaced them. If that sounds like your situation, read up on accessing built-in screen recorder next.

A wrong or missing header is the clearest single sign of overwrite. Combine it with a 0-byte or near-zero result and the file is gone, regardless of which tool you point at it. The bytes are not damaged, they are other data now.

One more check settles it. If you know roughly what was written after the deletion, a file that should be a photo and now contains the signature of a log or a database fragment confirms the overwrite. At that point more scans cost time and risk the files you have not yet recovered.

• Header wrong and size zero: the file is gone, stop scanning this drive.
• Header wrong but size large: a carver matched a different data type over the same sectors.
• Header right and size right: recover the file and move on.
• Header right and size small: re-carve once, then accept the result.

How to stop this happening again

The single fix that matters is keeping the source drive idle from the moment you notice the loss. Unplug it if it is external, or power the machine down if it is the system drive, and do all your scanning from a different computer or a live USB.

Set recovery tools to write to a different drive by default. Most allow you to pick an output folder; make that an external drive with enough free space, and never the drive you are scanning.

Backups are the only method that removes the guesswork. A cloud sync folder, an external drive on a schedule, or a second copy on a phone all beat any carver, because they keep the file as it was, with its name and its size.

1. Unplug or power down the source drive as soon as you notice the loss.
2. Connect a separate drive with free space for the recovered files.
3. Run the scan from another machine or a live USB.
4. Point the output folder at the separate drive.
5. Restore from backup instead if you have one, and only carve as a last resort.

Questions people still ask

I have sat with a folder of 4 KB photos and learned the size column answers the question before any tool does.