Jump to content
CCleaner Community Forums
Robert_F

Recuva is not locating any of my deleted files.

Recommended Posts

Hello all.

 

Since one of my brother-in-laws recently experience a serious loss of files on his work computer I began testing out Recuva for its ability to find deleted or lost files: I first tried Recuva Portable and then the version that installs on the computer. Since I had no lost or accidentally deleted files myself I made copies of several images and then deleted them, firstly from their original 'Pictures' folder and then from the recycle bin to imiitate an accidental deletion. I then ran Recuva (portable & later the installed version) in an effort to recover these 'accidentally' deleted image files. I tried initially the following settings for the search:

 

(Please note that my hard drive is kept well defragmented and still has about 100 GB of free space available so fragmentation of the drive would not have contributed to the following results):

 

1) Specific folder search ('My Pictures');

2) Recycle bin search (where the images were last located before deletion);

3) Whole computer search for pictures;

4) Whole computer search for all files types.

 

Not only did these searches fail to find the images that I had deleted only minutes earlier, but none of the files that were located - based on their location and names - were 'user' files, i.e. files opened in MS Office programs like Word or Excel, image editors (e.g. Adobe Photoshop), music files and videos, all of which are ordinarily placed in the 'My Documents' (XP)/'Documents' (Vista upwards) folder. Oddly, whether I was searching in a specific folder ('My Pictures') or the whole computer (all file types) Recuva said that it found about 79 thousand files, which it ignored: other than the fact that I have never had 79 thousand images in the 'My Pictures' folder, why would the program turn up the same number of files for an image folder as for the entire computer including all file types?

 

I tested Recuva Portable on another WIndows XP computer with similar results.

 

At this point Recuva is not looking very useful, but if there is a good reason for me to change my mind I am willing to listen to an informed explanation.

 

I am using Windows XP SP3 and so I wondered whether Recuva's poor performance might be due to it being designed more specifically for later WIndows architecture (Vista, Windows 7, Windows 8)?

 

Cheers.

Share this post


Link to post
Share on other sites

The 79k files ignored are the total of all files on your pc, zero length, system files, and non-deleted files, irrespective of what filters you apply.

 

Creating a file and then deleting it is the worst case for testing Recuva, or any other recovery program, as these files are most susceptible for immediate overwrite by another file. If you want to do this test then open Recuva, run a scan, then create and delete your file, then scan again. You will, or should, then see your deleted file.

 

I'm not sure what you mean about found files not being user files.

 

There's no functional difference between  the portable and installed versions of Recuva, nor the Op sys used, for what you are attempting.

Share this post


Link to post
Share on other sites

Augeas, hi.

 

Thanks for replying.

 

I have tried your scenario: 1) run Recuva, 2) create and delete file (from original folder and recycle bin), 3) run Recuva again, but this did not turn up the deleted file.

 

My first search was for pictures in a specific location, namely, the 'My Pictures' folder: no images found;

Secondly, I searched for pictures on the whole computer, which again failed to turn up the deleted file.

 

Also, to clarify, by 'user' files I mean those normally stored in 'My Documents', NOT system files or files in the 'Programs' folder or 'Application Data'. If I do a search with Recuva for all file types or even just pictures on the whole computer none of the results are from the 'My Documents' folder (where, incidentally, my deleted image came from); many are from the Programs folder and some from Application Data. File types include .ini, .bin, .map, .dll, and .dat files. Some png's, for example, turn up, but these tend to be from an Application Data folder, never from 'My Documents' (these are usually, if not always, from the Firefox thumbnails sub-folder under 'Local Settings'). So, why is Recuva not picking up my deleted file from 'My Documents'? Your own suggestion implies that this behaviour is not to be expected.

 

Thanks again.

Share this post


Link to post
Share on other sites

It's very difficult to know exactly what you (or any poster) is doing.

 

When you ran Recuva, did you scan and then leave Recuca open, create and delete your file, and then scan again?

 

Deleting a file via the recycler is different from a simple shift/del, The file sent to the recycler no longer lives in My Pictures, so it is no use looking there. Also Windows renames files sent to the recycler, so when you scan with Recuva you might not see the file under its original name (when I've tried this the file always regains its original name, I don't know what causes this inconsistency).

Share this post


Link to post
Share on other sites

Augea, hi.

 

Finally, success.

 

The key appeared to be leaving Recuva open after the initial scan: 1) I tried the recovery again without at first doing this and the deleted file was not found; 2) I performed the scan, left open Recuva and then deleted the file from the pictures folder and recycle bin. I performed the scan again (for pictures on the whole computer) and the deleted file appeared, re-named as dc2.jpg, with a file path indicating the recycle bin. I then successfully restored the image to the desktop.

 

I tried procedure (2) again with a second image, immediately performing a new scan - without closing Recuva - deleting the second image, scanning for it and finding it as dc3.jpg, which I also successfully restored. Hopefully this procedure will work as successfully if I lose a file for real. I will experiment some more.

 

Thanks for your help.

 

Robert.

Share this post


Link to post
Share on other sites

To anyone listening, hi.

 

When I submitted my last post I was beginning to feel that I might be getting somewhere with testing out the usefulness of Recuva in a common scenario, which Piriform claims the program deals with well, but something has been bothering me; maybe ultimately it may help. Piriform states:

 

Accidentally deleted an important file? Lost something important when your computer crashed? No problem! Recuva recovers files deleted from your Windows computer, Recycle Bin, digital camera card, or MP3 player.

 

My testing focuses on the first question, 'accidentally deleted an important file? . . . No problem!' Unfortunately, my tests as outlined above do indicate a problem. To achieve success I had to, 1) firstly perform a scan for the file I had not yet deleted, 2) delete the file I wanted to recover, and 3) perform a second scan to retrieve the file.

 

In a real scenario, however, I would have, 1) deleted the file I did not realize I needed and 2) performed a scan with Recuva in the hope of retrieving it. As explained in my earlier posts, however, in this more realistic scenario the deleted file was never found by Recuva.

 

It may be that there are other scenarios in which Recuva works better, but in this one, included by Piriform in its description of Recuva's capabilities, it does not appear to work. If someone else has a different experience it will be interesting to hear about it.

 

Robert.

Share this post


Link to post
Share on other sites

In the documentation it is stated many times that there are circumstances where Recuva won't recover every file. It specifically says that:

 

'Ironically, the shorter the life of the file, the harder it will also be to recover. Say you create test.txt at 9:01am and delete it at 9:10am. Chances are, it will be quickly overwritten by temporary files.'

Share this post


Link to post
Share on other sites

Augeas, hi.

 

With respect you are missing the point. If I attempt to recover a file in the three-stage manner you suggested Recuva finds the file EVERY time, there is no issue with the file being overwritten by a temporary or other file, but as I said above this method is not possible in a real situation where one has accidentally deleted a file: as we discussed above your three-stage method requires that I first scan for a file that I have not yet deleted, THEN delete the file and perform a second scan and we have established that this works every time, the file IS found; but in a real life situation no-one is going to scan for a file before it is deleted, all one can do is scan for the lost file, but unlike in your three-stage search method this does not work.

 

So, we have two questions: 1) why does Recuva fail to find the files in the 'real life' scenario? and 2) Why does it find the files consistently when performing a first scan before the file is deleted? Could it be that in the case of (2) Recuva, during the first scan, makes a note of what files are present and then during the second scan identifies the files that are now missing? If not I do not understand why the first scan would make any difference.

 

Must go.

 

Robert.

Share this post


Link to post
Share on other sites

The answer was given in posts two and seven (and now post nine). I would ask you to read all the responses carefully.

 

When any file is created it uses the first available record in ascending sequence in the Master File Table. If a file is created and then immediately deleted the record in the MFT is instantly available for use by any other file creation, and is quite likely to be the first available record again. So any activity, such as starting Recuva, or any system activity such as writing prefetch files, logs, virus checks etc, can use the MFT record, thus losing the chance to recover your file. The point of running Recuva first is an exercise to bypass all those extraneous activities to show that the file is there, and to indicate that it's those activities that make the file unrecoverable.

 

You seem to be asking the same question, and I'm giving the same answer. The operating system overwrites the MFT records of newly created/deleted files very quickly. Neither Recuva nor any software application can find these files by looking at the MFT.

Share this post


Link to post
Share on other sites

Augeaus, hi.

 

In fact contrary to your assertion (post #9) I have not simply been repeating myself, but have raised several different issues that you have evidently failed to recognize. Nevertheless, I am not going to rehash those points here, but will instead briefly sum up what I have learned from this correspondence and my various tests in the hope that it will help somebody and perhaps even lead to an improvement in the software, which given what it is supposed to do might be regarded as having a bug.

 

  1. If a file is deleted BEFORE opening Recuva using the program to scan for it immediately afterwards does not find it;
  2. If a file is deleted AFTER opening Recuva using the program to scan for it immediately afterwards does find it, in my experience consistently and also successfully restores the file;
  3. If a file is deleted AFTER opening Recuva, BUT another program (e.g. Windows Media Player) is opened BEFORE Recuva is used to find the file it is not, in my tests, found.

 

Augeaus this in large part supports your statement in the last post that, “ . . . any activity, such as starting Recuva, or any system activity. . .  can use the MFT record, thus losing the chance to recover your file.” Unfortunately, for the user this means that opening Recuva to locate and recover a file that one has just accidentally deleted – as is consistently shown in my tests – does itself prevent that file from being found: this is what I mean by a 'bug'. When Piriform, in promoting Recuva, states, “accidentally deleted an important file? . . . No problem!” there is no indication that this should be the case. It does not appear, however, that files deleted in the way discussed here are as vulnerable to being lost forever as you suggest.

 

If Recuva was opened on first booting up the computer and left open a search for a lost file immediately after deletion will, according to my tests, be successful. Of course, I can only be as certain as my test results, but in every case that I have followed procedure (2) above, which I have performed many times, the lost file is found and recovered.

 

I do not wish to belabour this issue further, but I hope this helps someone. Thanks for your help.

Share this post


Link to post
Share on other sites

Despite Piriform's hyperbole, this is not a bug. It's the file system that overwrites the MFT records. No software in the world can prevent this. No software in the world can guarantee to recover any and all deleted files. Piriform's documentation - part quoted above in post seven - states this.

Share this post


Link to post
Share on other sites

In my view it is ALWAYS USER ERROR if he holds his files on System Drive C:\ which is constantly over-written as Windows is running.

 

If the user holds his files in a different partition then recovery is more likely to be successful

REGARDLESS of which recovery utility is employed.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...