Save Scan Results
Posted 19 September 2012 - 05:51 PM
Posted 19 September 2012 - 05:59 PM
Posted 19 September 2012 - 07:29 PM
this is absolutely true
In any event the results will change quite rapidly, so the value of a saved list diminishes
DON'T JUST CLEAN EVERYTHING THAT'S CHECKED OFF.
Do your Registry Cleaning in small bits (at the very least Check-mark by Check-mark)
ALWAYS BACKUP THE ENTRY, YOU NEVER KNOW WHAT YOU'LL BREAK IF YOU DON'T.
CCLEANER, RECUVA, DEFRAGGLER AND SPECCY DOCUMENTATION CAN BE FOUND AT www.piriform.com/docs
Link to Winapp2.ini explanation
Posted 23 September 2012 - 08:33 PM
For example - every time I am forced to build the list with a deep scan it take about 20 hrs - if I was able to save the file then it would only take me a few moments to load and resume my recovery activity.
Another good option would be to be able to sort by file extension or filter by wild card but not lose the scan. - with the display it would be nice to be able to turn on or off more than one option like preview and header at the same time.
When the file is saved to text file it is nice that it is done with tabs / this makes it easier to import into excel and sort but I would have liked all the columns to be exported not just the 3. Not sure why the date was dropped or the status.
Posted 23 September 2012 - 10:22 PM
I also agree that this can be a mega time saver if one is scanning a large drive with deep scanning.
Some drives may be on their last legs, & it may be that avoiding a 5+ hour re-scan is just the trick needed to get em off that 1 last time before she ker-plunks!!!
So, +1 from me.
Posted 24 September 2012 - 05:30 AM
The idea of a list as a record is fine, and indeed exists already, but the previous two posts mention reloading the list instead of rescanning, which is a different kettle of fish.
The only way a disk (partition really) would remain unchanged is if it were on a top shelf in a cupboard. Possibly most users run Recuva against their system disk, which certainly changes. In any event Recuva would be foolish, even dangerous, if it assumed that nothing had changed.
The list as shown is missing some elements. You would need at least the start cluster and number of clusters for each extent in the file. With some files there can be hundreds of extents, and a single entry in the list could be many k's in length, and the list hundreds of mb's. For the users who need the list most, i.e. the terabyte disk owners, the problem would be the worst with a huge list to manipulate.
When the list is reloaded there would have to be verification to check whether the cluster status had changed (I would hope that Recuva does this anyway before any action). I don't know how Recuva does this, but presumably it can be done without a rescan.
There are also other considerations. The automatic mini-defrag of Prefetch, and some users would defrag anyway between taking and reloading the list. Should the list expire after a period of time? Yes, but how to do that?
Other things - Greg, you can change any filter option without losing the scan. Recuva will alwats do a full scan whatever is in the filter boxes, so run an unfiltered scan and then apply filter afterwards. I'm not sure what you mean by turning off preview and header.
SF, all you need to do is save the list just before the disk fails. I can't see a setting for that!
Posted 26 September 2012 - 04:47 PM
1. For me some of the concerns are raised are not as important to me because my concern is time savings and if some of the underlying data was changed due to a defrag or the startup on the prime drive then so be it. I would have lost this anyway and the product does a good job today at reporting a recovery failure.
2. The text list is basically useless for me for it does not do anything nor does it save me any time .. just fun for searching with wild cards which is usefull - but I would certainly not take the feature out for I like the record aspect of it.
3. Thanks for the note on the filtering / this was my own mistake / very nice - thank you.
4. I would assume that the data structure currently used would have to be stored on a disk that was not in use or at ones discretion for it would write over some areas. - In my past we used to record the free space in order to write protected blocks without damaging data but that was a long time ago and I do not know if the current disk architecture makes these techniques obsolete.
5. I would not expire the list simply report the date / drive for the header. The reason I say this is I personally would like to compare more than one list at a time but with a lot more detail only found in the online version.
6. As to the size of the list - this is not an issue for me based on the the fact that the current list is only in RAM. As to the much larger systems I am not sure if this program would be used for they are probably RAID and if we all start to get to this size then all other factors will change too.
To emphasize the point I just had to scan again - 20hrs and the drive went wonky(technical term ) again so I had to wait another 20hrs. .....