Faster Recuva Results

Recuva Recuva Suggestions
1

Recuva is a great program, with great features.

But it also has a great problem.

The wait.

_____

The bigger the drive you are recovering, & especially if you have deep scan enabled, the longer the wait.

Recuva certainly finds files while it is scanning, but it delays showing the user anything at all, until it processes the entire drive.

This is really un-necessary.

Many users may wasted hours on 2,000 + GB systems, & it is only gonna get worse as drive capacity increases.

_____

Can you guys please add a way that Recuva can show the files AS it finds them? Because sometimes, the files truly can be found in seconds, or in minutes. You can't keep hitting Cancel, because if it hasn't found them, you start all over, wasting still MORE time.

Would really love if Recuva will display the results real time, as it finds them, & display the exact folder structure that Windows uses.

Example: User deleted a wallpaper they wanted from C:\Windows\Web\Wallpaper\Some kind of .jpg

_____

When Recuva finds that file, it could create the folder structure C:\Windows\Web\Wallpaper, then show the jpg that was deleted inside that folder.

Not only would this save people a ton of time, as they can see folders instantly added to the tree as Recuva finds the files that are deleted from them, but it would make it a lot simpler & quicker to recover.

_____

Currently, if a user loses 5,000 wallpapers in a folder, a user has to highlight 5,000 or so files to recover, instead of just being able to select a Wallpaper folder, then right-click the folder, & recover everything with a single selection.

I hear so many people complain about the wait, & to tell you the truth, that is the one thing that bothers me with Recuva, is that it doesn't do real time display of the results. And that when it does display them, you have to scroll page after page after page after page in order to highlight all the files you need to recover. PHEW! Done! Hours later though....

_____

Love the program! Could you guys do something like this, so that a user is able to cancel scanning a 2 or 3 TB drive after they find the files? I hate to think of users scanning all night long, when it is very possible that Recuva will find the exact file they needed in 5 minutes. Not only is this terrible for drive life, it's also terrible for the wait.

Add real time updating with exact Windows Tree generation, please! I want to be able to recover all the wallpaper in a folder with a single right-click on that wallpaper folder, rather than waiting hours to recover them by scrolling through pages of results.

_____

Thanks!

2

Well, I'm no statistician (I can't even spell it) but isn't the average time of a sequential read to find any item from a random list half the time to takes to scan the entire list? So the hapless user looking for one file would have to wait on average half the night, and to find his or her 5000 wallpapers would probably take 99% of the full scan time.

Now if Recuva showed the results of the scan in real time, the list would whizz past me far faster than I could read them. I guess that it could show the tree structure, and then the user could open the required folder to see what the contents are. Then the user would have to wait, on average, half the scan time for one file, etc. For folders with many files - and 5000 is a massive amount for me - how would the user know when all the files had been found, except by waiting until the scan had completed?

When Recuva has completed its scan you don't have to look through pages and pages of results. Just switch to tree view and open, or recover, the required folder. But see below.

Real-time results display has merit, in as much as it will satisfy users who want to see some action. But it will only save time in a few lucky cases. For everyone else it's probably better to go to bed.

I should add that for a normal scan the tree structure has a good chance of being resurrected from cross-references to folder records in the MFT. But a normal scan is fairly fast anyway. In a deep scan the additional files found don't have an MFT entry, they don't in general have any reference to a folder structure, and they don't even have file names. They're just clusters of data lying at the foot of the tree.

3

@ Augeas. That was only an example, so that a user could comprehend the need for the function.

"Now, if Recuva showed the results in real time, the list would whizz past me far faster than I could read them"

Not really... That is what the exact tree structure is for. If Recuva builds the tree structure as it finds the files, there will be simply C:\Users, C:\Program Files, C\Windows directories in the Recuva structure list.

_____

Which is easier to navigate? The 3 or 4 Windows folders & right-click the folder you knew the files were in to recover them?

Or list a few thousands of files, then hunt for the ones you knew were missing in the list & individually select them after you scroll past a few dozens of screens?

As to saving time, this method works. The reason I know it does, is because I have a data recovery program that does precisely that.

I would say, that in 90-99% of the cases, I can find the exact file(s) I need in just 1-5 min, as opposed to hours with Recuva.

Because Recuva makes you wait. Sure, if they have 5,000 wallpapers, they may have to wait a little longer, but in the majority of cases, they have a few documents, or a single file they deleted that is very important. You can tell when they are there, because once Recuva finds that file & creates that folder, all you have to do is look at the total # files found in the list at the bottom of the page.

Most programs do enumerate the # files in a folder at the bottom of the page.

_____

I would not even mention this, if I had not tried it & it already works. But I have, & it does work. I have a program right now, that can find files using above method in less than 5 min in 95% of the cases, where Recuva makes you wait the entire time. It does work! And it is much faster & easier to see when the file(s) are there via navigating a "windows directory clone" that gets generated as files are found, than to navigate through billions of files on the same screen.

This particular program that I use a lot, let me give you an example:

Suppose you deleted a file that was in C:\Users\Augeas\My Pictures

The program will scan for deleted files. C:\Users\Augeas\My Pictures does not exist in the tree initially.

But, as it finds file, it finds the one(s) that were deleted from your My Pictures folder. So, it adds C:\Users\Augeas\My Pictures structure when it finds that deleted file. Very simple. User knows it was in the C:\Users\Augeas\My Pictures folder, so they instantly know that when that gets added to the tree, it must have found that deleted file.

_____

And in this program I use, it also has where if something is a picture or text file, you can just click it & it shows a preview in the bottom pane so you can see if that is what you want to recover. Very, very handy.

If this feature is added, at least as a directory structure option in Recuva Options, it will stave all the complaints that Recuva is slow. It's not really that Recuva is so slow. Well, actually it is! Recuva finds files perhaps as fast as other programs, but it delays showing its findings till after it finds them all. In other programs, you may find your files in 5 min or less. Once in a while, you might have to wait. But that is not as often as you would think.

If you want to, you can download the evaluation version of Handy Recovery to see what I mean. While it is a trial for 30 days, & allows recovery for 1 file at the time, it should show you how it works. I myself have the full version, which I am quite happy with, as it does what it says on the tin so to speak. I wish you would download it, just for testing purposes, then post back up here after trying it a few times, & let me know which way works faster.

_____

I have used it a lot, & it is definitely faster. Much, much, much faster. I would not post here at all about it, but I have used it a lot, & I have tried Recuva a lot, & to this day, Recuva cannot hold a candle to it because of this. If real-time updating were added, Recuva would have the other contenders nearly knocked out.

And the final feature Recuva doesn't have is the ability to recover from "RAW" drives, or to scan for corrupted/missing partition info. This also exists in Handy Recovery, & though Recuva works when it can see a drive, Handy Recovery works even with "deleted/Raw/corrupted" partitions. It also can recover from password protected user accounts (sometimes a user account gets corrupted, & user loses ability to log in).

But, I just want you to download the trial, delete a few files that you already have copies of backed up somewhere, then just try this program compared to Recuva. After you try it a few times, you post back here & tell me again that Recuva is just as fast. Because I know its not.

_____

I love Recuva, but it is just too slow in posting results! Try what I listed above, & if I am wrong, then write back after trying that program & tell me I am wrong.

Thank you!

*** P.S. And I know it isn't polite to mention contenders, but it seems there is no way to get anyone to know what I am talking about, without trying it. Hope you understand. Thanks!

4

Whilst this is an interesting suggestion, there are perfectly good and demonstrable reasons why it will be of little benefit. These have nothing to do with Recuva or any software, and everything to do with NTFS, which was not designed in any way to help users to recover deleted files.

A quick mention first about Recuva: it runs a primary and secondary scan. If it were to build up full info for files in real time then it would have to do both scan stages for each file as it went along, which would probably not be very efficient. I wont dwell on this.

Normal Scan: Recuva reads the entire MFT sequentially. It checks the status flags in each MFT record and notes those which are deleted files. It extracts the file names and cluster runs from the MFT record. In each MFT file record is an address of the owning folder. Recuva can then build up the tree structure.

If the folder record is unavailable (it has been deleted and subsequently overwritten) then the file record is an orphan and is tagged as belonging to C:\?\

So far so average, Many of the deleted files can be placed in the correct folder, and the tree structure built. Some file records, mainly from folder deletion, will be orphaned.

The MFT does not arrange records in name order, but uses the first free record (in sequence) to assign a new file. Thus files are distributed apparently in random name order in the MFT. And thusser still, you would have to read the entire MFT to be sure of finding all deleted records.

Deep Scan: A deep scan runs the normal scan first and then reads each unused cluster on the disk. This is a far more complex process than the normal scan. There is no indication within each cluster whether the data is live or dead, or indeed whether it is a file at all. I would guess that Recuva uses the cluster bitmap to identify unused clusters, but I may be wrong. In what order? I don't know, but if the bitmap is read then it would be reasonable to read it in order, which is from cluster 0 to cluster nnnnn.

When a cluster is read Recuva looks for a file signature in the first few bytes. If a recognisable signature is found then the cluster is placed in the files found list.

Right. If you run a deep scan, or look at a few clusters with WinHex or something similar, it's apparent that there is no file name information held there, nor is there any folder information, nor is there any multiple extent information. Of course not, it's all in the MFT. So the overwhelming majority of files found during a deep scan will be orphans, and the 'recover the tree' option will not be there.

Look at the tree structure after a deep scan. What percentage of files are listed under C:\? (I need another question mark there). That will vary of course, but it will be significantly high, possibly in the 80 to 90%'s. A tree structure will not help these files, nor will it help the user to group or recover these files.

Randomness. Although files are not placed on a disk in a random manner (Bill won't tell me how it's done) they are certainly not placed in file name order. So to find a particular file name you will have to read a substantial part of the disk, on average half. You just can't get away from this, unless you're constantly creating and deleting the same file at the start of the disk.

I know the process is far more complex than I've described, Recuva's results still puzzle me a little. Please excuse any gross errors, Piriform.