Francis Favorini

OK, cool. Specs for the machine in question are dual Xeon 3.6 GHz, 3 GB RAM. OS is 64-bit Windows 2003 R2 SP2. If you can tell me how much RAM I need, I will try to steal some from other machines and see if it works. Also, if there were a way to set a filter so that resources are not kept around for files that don't match the filter, that would reduce the amount of memory needed. In my can, all of the files start with a known path (E:\Data\Some\Dir\). Most of the deleted files are in other directory trees, so storing their info is not necessary. The above discussion goes into more detail. Let me know if this is not clear. Thanks, Fran

For completeness, here are the other programs I've tried: EASEUS Deleted File Recovery Free Undelete Glary Undelete Pandora PCInspector File Recovery Undelete & Unerase RecoverFiles Restoration TestDisk & PhotoRec UndeletePlus Uneraser They all either crashed at some point, complained the disk was corrupt (it isn't), or were taking so long it didn't seem likely they would work.

So I've been running another program (PC Inspector File Recovery) all weekend, and it has only used 400K of RAM, but it's only about 37% done with the scan. It says "Retrieving existing files and directories", which makes me worry a bit that it isn't scanning deleted files yet. Not sure if I want to wait for this to finish or try something else (like Active@ File Recovery). I suppose I could run Active@ scan while the other one is still scanning, since both should only be reading from the disk.

Yes, one folder including all of its subfolders. The subfolders do not have unique names across the filesystem. It doesn't seem there is any way to restore things a bit at a time anyhow. If I undelete any particular file, it will be restored to another drive, leaving the original drive in exactly the same state. Hence, a subsequent scan will have exactly the same memory issues. Yes, I would be happy to cancel Stage 2, but it never gets there. It just stays at the end of Stage 1. I suppose I could let it run for a few days and see what happens. Yeah, I put in the path to the files I want. Didn't seem to change the memory usage or hanging at the end of Stage 1. (When I say hang, it may be that it's just really, really slow because of the huge amount of virtual memory it's using.) When you clicked Cancel, did the dialog box say it was on Stage 2 or Stage 1 with 100% complete? Mine stays on Stage 1 with 100% complete. It may be trying to sort the list or something, which is taking forever. It's RAID 5. Thanks for any help you can think of.

Tried cancelling when it said Stage 1, 100% complete, but it just sat there and did nothing. Had to kill the process. Perhaps I should've waited longer than 15 minutes. It seems that it's using the page file heavily at this point, so it's very slow. Does anyone know what Recuva's actually doing at this point (before Stage 2 starts)? I figured as much. Yeah, I have selected the correct disk. I just wish it would not save the info for the directories I don't care about. That would make the memory issue go away. So close...

Note, I am not doing a deep scan, so Recuva should only be looking in the MFT for entries marked deleted, right? If so, there should (at least in theory) be a way to specify a path instead of just a drive to return results for. The MFT still includes the names of all deleted files and directories, as I understand it. Apparently, Recuva is storing some bits of info for each file it finds in the MFT marked as deleted. That's the problem, since there are 14 million of them. If it would only store that info for the files in the path (i.e., the whole directory subtree) that I want, it should have enough memory ("only" 700K files). Filtering the list of files after it is built is no good, since it takes too much memory (apparently) to build the whole list. I thought of trying to restore some files, even those I don't care about, to reduce the total number of deleted files. I am worried that this might cause some blocks on the disk to get written to, however. I suppose in theory, all it should have to do is unset the deleted bit in the MFT, but I'm not exactly sure how this works. If I instead restore the (unwanted) files to a different disk, it won't help, since they will still be marked deleted on the original disk. What would help is if there were some way to ignore those unwanted files. Also, there is no way using attributes, dates, or filenames to get just the files I want. The only way is to specify the base directory (and yes, I want the whole subtree, not just one directory). -Fran

Folks, I deleted a bunch of files (about 14.8 million). Turns out I need about 700 thousand of them back. They are all in a single directory tree. Nothing has been written to the disk since. Scanning the MFT should find everything. The problem I am having is that no software I've tried so far can deal with that many deleted files without running out of memory or hanging, including Recuva. System has RAID array with 2.75 TB, dual Xeon 3.6 GHz, 3 GB RAM. Recuva went all the way through to the end of Stage 1, reporting 14,840,569 files, 100%, 0 seconds left. Then it just sat there. Left it overnight, no change. It was using about 2.8 GB of RAM and occasionally a 1% of CPU. Pagefile was up to 22 GB. Finally had to kill the process. Maddening. Is there some way I can tell Recuva only to process files in the directory tree that I care about (say F:\data\important\stuff) during Stage 1 (and 2)? Would it actually have finished if I had left it? Any way to tell what it was doing? Any other programs out there that deal with memory in a better way? Thanks, Fran