Martinw27

Third run of Recuva duplicated the results of the second run, described above, with the same error message. Attached is the debug log of the run. Once again, the scan reached 100% and then began spewing out error messages "Invalid Clusters Range" and was unable to recover any files at all. As I mentioned, the all-or-nothing approach used by Recuva is self-defeating and means I cannot use it to recover my files, because it doesn't save the information as it goes. If it were to log every file found and place it into a file of my choosing on another drive, and then be able to use the file to go and recover the files it found, that would be an improvement. A bigger improvement would be for it to list the files in the main window as it goes, and not close the window when it encounters an error. Still better would be to make it ask for a drive/directory where the recovered files could be saved and to save those files so that one could examine them and restore the wanted ones after the scan is done (errors or not.) I will now have to look for other methods to recover the files I know are present. The Disk Utilites package I have, which includes Partition Commander 10 Pro, doesn't appear to have any recovery program that works on a reformatted partition to recover the data that is still on it. In addition, many of my files on that drive that I want to recover were generated by WordPerfect 11, 8 or 6 - all have the same basic format though 6 is slightly different. A program that specifically can recover .wpd and .wp files is needed. Among image files there are several types I want to recover including .pcx, .wpg, .tif, .wmf, as well as the supported .png, .bmp and .jpg types. Other document types I want to recover are .doc, .xls, .ppt, .ppd, .pps. .xlt, .dot (Microsoft); .ws (WordStar 4); .wpd, .wpt, .wpg, .qpw (Corel); .sch, .dat, .prb, .cir, (Microsim), .vb, .vbs, (Visual Basic), .fcd, .fcw, (Fastcad), and many more - mostly related to technical applications or older DOS and Windows applications. Some of these are simply text files stored with a different extension, so should be recoverable. If you have a fix for these problems, let me know. Meanwhile, I'll appreciate any alternative solutions you can recommend. Recuva_log_1_30_435__11_9_2009_19_40_.txt Recuva_log_1_30_435__11_9_2009_19_40_.txt

Last few progress entries: 6:36 p.m. 94% 1 hour 690343 files 6:40:10 95% 60 min 690343 files 6:45:22 95% 50 min 690343 files 6:49:45 96% 50 min 690343 files 6:55:46 96% 40 min 690343 files 6:59:00 97% 30 min 690343 files 7:09:55 98% 25 min 690343 files 7:14:02 98% 20 min 690343 files 7:17:46 99% 10 min 690343 files 7:21:27 99% 5 min 690343 files 7:25:06 100% 0 min 710799 files 7:28:12 Scan window closed, no files listed in main window at all Message at bottom left "Invalid Clusters Range" Restarted with /debug at 7:41:05 p.m. It appears that one error in the window prevents all files from being displayed. Pretty robust software, isn't it! :-( As I mentioned before, can we get the program to record the files information AS IT GOES and recover the files that don't have invalid clusters, PLEASE!!! If MrRon is watching this list, please respond to my concerns with a detailed action plan to resolve these issues.

Slow progress report: 8:18 a.m. 34% 14 hours 636640 files 9:43 a.m. 41% 12 hours 636640 files 11:05 a.m. 50% 10 hours 636640 files 4:57 p.m. 84% 3 hours 690343 files 5:02 p.m. 85% 3 hours 690343 files * changed %age 5:39 p.m. 87% 2 hours 690343 files 5:41 p.m. 88% 2 hours 690343 files * changed %age Estimated based on 3% in 39 min. is that remaining 12% would take 2 hours 36 min finishing at 8:17 p.m. Scan was started some time before 2 a.m.

New run started yesterday evening, running as Administrator in Safe Mode to minimize other running processes. Taskmgr shows 16 other processes running. At 8:18a.m. the scan window showed Stage 1 of 2: scanning drive for deleted files|Current progress:34%, 636640 files found|Estimated time left: 15 hours. Currently at 9:43a.m. it shows Current Progress: 41%, 636640 files found|Estimated time left: 12 hours. The computer is a Sony Vaio originally having Windows Me installed, upgraded to Windows XP Home SP2 a year or two ago, and it has upgraded itself to SP3. 512Mb RAM installed, 866MHz Intel Celeron processor, two HDDs 40GB and 300GB. Recuva version is 1.30.435. If this doesn't work, I'll start a new run with /debug and see what I get. I know the stuff I want is there, mainly .wpd and .pdf files near the top end of the 100.1GB partition D. Q1: Why so slow? I see some forum users having a complete drive scanned in a couple of hours. Q2: Why not have the recovery window show the files found as they are found instead of having to wait until the end of scanning? Q3: Why not allow users to interrupt the scan at any point and recover the files so far found? Q4: To go one stage further, why not have the program do deep scanning and automatically save the files found on a specified different drive e.g. a folder on the USB drive I mentioned, as it is scanning? It's easy to delete the recovered files you don't want, but much harder to recover them if the program has to do it in one shot, and impossible if it crashes.

I had the same problem. After it reached 98% on scan #1 with 25 min. to go, it crashed and the files list was empty. Tried restarting the scan but it went back to square 1 and started over. As the computer is slower, it takes almost 24 hours to find just over 690,000 files, and it never gets to stage 2, whatever that is. What it needs is a progress file that can be logged on a different disk and from which it can continue scanning where it left off, also it needs to be crash proof. It also needs to recognize many more file types unambiguously. Example: WordPerfect can also use a .doc format but generally saves as .wpd format. The program also needs to distinguish between a Microsim .sch (schematic) file and a Microsoft .sch (Schedule) file. Wordstar uses the .WS extension, and my disk includes backups of old Wordstar files. There are many other examples. Restricting the formats recognized to just a few common ones and misidentifying some formats fom their extensions doesnt always work. The program needs to get a lot smarter!

While you're looking into it: My Windows XP SP3 computer has a data drive D with 100GB capacity (partition on a 300GB drive that is in use and working.) Recuva deep scan got to 690,000 files and 98%, with 25 min left, after a full day of scanning. 15 min. later the scanning window had disappeared and it showed no files at all in the main window. Hence I cannot recover any files (to an external USB drive with 160GB free.) I am disappointed that according to the posts here it looks as if no amount of retrying will in fact get the list of files that it can recover. The original need arose because while I was repartitioning the HDD the computer crashed, leaving the bottom 200GB in an unformatted and unrecoverable state. As I knew there was less that 100GB in the partition, I used Partition Commander 10 to put in a new 100GB partition in the space above the known data. I had to reformat the 200GB partition to NTFS before that would work, but since then have left the bottom partition D alone and restored most of my original data to the upper 100GB partition, with the intention of recovering the lost data later. All that is in that partition is the Recycler folder. I can tell that the data is in fact there, as I tried a different utility before Recuva, which listed some 29,000 files (suspiciously all the same size) and I was able to recover a few to the USB drive and examine them with an ancient DOS PATCH utility, from which I could read that a .gif file contained the ,gif image, plus files created by PSPICE, WordPerfect, WordStar and other programs. All the files recovered with that program were the same 1.43MB size. Consequently I wasn't surprised to see Recuva finding 690,000+ files as many of them are much smaller than 1.43MB. However it's no use to me if after a day of running my HDD at 100% it fails to list the files that can be recovered and do the job. For a program that is at the top of the top ten list this is unacceptable.