Mos Eisley

Even if it's a "lost" partition that Windows sees as only raw data? That shouldn't be happening. At the very least, being able to pause a scan for cooling might be helpful. An option to automatically pause after X minutes of scanning then resume after Y minutes of cooling might mitigate overheating issues. Or if adding the ability to monitor the drive temperature isn't too far beyond the scope of Recuva, an option to pause scanning when temperature rises above X and resume once it's dropped down to Y would be even better. In any case I'm setting up a fan to blow across my drive dock to hopefully keep it cool.

It would be extremely useful if a scan session could be paused, saved, and resumed, so that if a scan needs to be interrupted for whatever reason a user doesn't have to start the process completely over. I was scanning my 4TB harddrive, but after it sat at 31% without any progress for nearly 4 whole days, I decided to check the drive temperature and found that it was 118℉. I decided that the drive must be overheating, so I cancelled the scan and am letting the drive cool. (It might also be getting hung up on bad sectors, so I'm going to try cloning the drive and seeing if recovery software has an easier time skipping over "bad sectors" on the copy.) If I didn't have to restart the scan from the beginning, not only would it save me time, but probably also save wear on my harddrive. Another use case is in the event of a power outage. I live in area that typically has brown-outs about once a month, and less frequently the power can be expected to go out for at least a few minutes if not half a day a couple times in the year. I do have a UPS, but it doesn't have enough power to run all day long; it just gives me enough time to save my work and shut everything down.

In my experience, devices that can function as independent portable devices, e.g. tablets and cell phones (let's call them "handhelds"), tend to communicate with an attached PC less cooperatively than something more "PC" like an external harddrive. A USB-connected harddrive will usually behave as if it's part of the PC's internal system, while a handheld seems to usually have an additional layer of abstraction between its file system and the PC. I have an MP3 player that responds resistingly to having a "New Folder" renamed directly on the device, so I'll usually name an empty folder on my PC before moving it to the MP3 player. I also can't just move files around on the MP3 player; if I "cut and paste" a file, Windows has to copy it from the device to a temporary location on the PC, delete the original, then copy the temporary file back to the device. When I connect my Kindle to my PC, I'm not able to view the full directory structure of the Kindle (so that I can't try to bypass Amazon's "pay extra to not be buggered by advertisements" feature). It may be that your handheld's abstraction layers are a barrier to Recuva, as such programs want more direct access to physical storage devices than normally accomplished via an operating system's typical methods of reading and writing files.

It's possible that some files were heavily fragmented and for whatever reason recuva couldn't quite put the right pieces together. I'm just theorizing on this next point on how Recuva might work, but one of many possible methods of data recovery is to locate and identify a table of contents (addresses of files on a disk) which might be "current," or might be an old version (from before some files were moved or otherwise rewritten), or might be partially corrupt, and then use this table to locate files. As a simplified example, a file might have an address of 12345, which in binary is 11000000111001. Through some random corruption, perhaps a hardware error or exposure to a magnetic fields, one random bit got changed; perhaps the first 1 changed to a 0, resulting in 01000000111001, which is 4153 in decimal. A recovery program might read this incorrect address of 4153 and then look in completely the wrong area of the disk for the file's data. I had a 2TB drive recovered (using some other software), and I would guess that 5-10% of the recovered files contained the wrong data. I was even able to recognize the some of the incorrect contents, e.g. one recovered image file contained a chunk of text that come from web pages, so it wasn't just random binary garbage (although image data replaced with text does amount to garbage output).

I'm currently in hour 29 of Stage 1, have "3 days remaining," and the progress bar has been stuck at 31% for the last 20 hours. I'm new to disk recovery (in practice) and have been reassured that this is normal behavior for recovering a large drive. No doubt then this could take even longer than 3 more days, but I can't help but getting antsy with a progress bar that isn't moving. Understandably recovery scans can take a very long time to complete, especially on a drive that is multiple terabytes large (this one is 4TB). This brings me to my feature request: If at all practical, a progress percentage display with, let's say, 3 digits of precision would help assure people that the scan is progressing and isn't stuck in a loop trap or some other software error. For example, then an hour later it might have incremented to That's not much progress, but it is nonetheless visible progress. Or maybe display more detailed activity progress info, like

It's possible that the wrong content was recovered, either because it had at some point been overwritten or maybe an older file pointer was used, or some other unfortunate corruption. I had a harddrive recovered using some other software (I'm not sure what, my brother did it for me), and maybe 5-10% of the files had the wrong content, e.g. an image file contained zero image data but instead a chunk of text that looked like it probably came from my web browser cache. To confirm whether your recovered file is corrupt, you can try opening it with MediaInfo (download the "without installer" package because the installer is bundled with unwanted junk) which is great at identifying media files. If you want to get very technical, you could also try opening the file in a hex editor like UltraEdit to confirm whether or not the file at least has a proper media header. Other options available using Recuva: Since you know the filename, run a scan that searches by filename. Run a scan that searches by file type. I can't confirm whether Recuva's search-by-file-type goes off of just the filename's extension or if it actually inspects the file contents for data signatures (and I can't investigate since I'm currently running a scan right now). Some recovery programs will even let you specify a custom binary signature to look for.