Jump to content
CCleaner Community Forums

Danno

Members
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Danno

  • Rank
    Newbie
  1. I am also having the slow full defrag problem. But, I've narrowed it a bit further for you... Turn on the option "Move large files to end of drive..." Turn on the option "Move only selected file types:" Change the "Minimum file size" to 1MB and put a bunch of files that will be caught by the filter onto the drive, along with a boot partition (i.e. 16K files about). For me, full defrag with this option turned off defragged my drive in about 1 minute. Turning the option on, and the defrag barely did any activity on the HD, but maxxed out a single core of my system to 100%. It also looks like you're not using parallel processing... That might not be helpful in this type of application though. Please try your tests using this configuration. Thanks! PS: Further updated information: I did a quick defrag which reduced my fragmentation to next to nothing, then did a full defrag with problem options enabled... After an initial delay after analysis, it performed quite quickly. Perhaps the issue will only surface while there's fragmentation present (it didn't have a problem with 2 fragments/16.1KB, but did with 327 fragments/10.7MB). Hope this helps you narrow the focus on the issue.
  2. I got the PM, and sent the email. I got the email back with a 550 error, user unknown. Do you have another suggestion for me?
  3. Maybe this is more of a suggestion than a bug, but... If Recuva hits a CRC error while scanning (which is likely if you're trying to recover from a disaster), it aborts. I'm trying to recover files from a formatted HD, and Recuva reports CRC errors. However, when I run scandisk /r /x, it finds no CRC errors. Any idea why Recuva is reporting CRC errors where scandisk doesn't report them? I've run in debug mode, but the generated log file is 4GB (3MB compressed), so to large to upload here... PS: I usable recovery method would be to either to continue scanning but log the CRC errors and indicate what files were affected by the problem sector, or prompt the user (way less friendly, as there could be lots of prompting on a flakey drive) and allow them the option to continue scanning.
  4. Scanning could give you a readout of what sector it is on (just eye candy really). ---- If you abort a scan during phase 1, it could ask you to "view already discovered files?" and then give you the results, as if it had completed the scan. This would help me in my current problem of a CRC error is causing the scan to abort, even though chkdsk /r /x is finding no errors on the drive (I've run in debug mode, and got a 4GB log file, which is 3MB compressed, just a bit big for sending here).
  5. Excellent, I didn't realize that. I will try to remember that for when I need it again.
  6. I was just noticing that sometimes I want to recover just a few types of files (though I might have forgotten a type when I started the scan). Would it be possible to have an option to "rescan existing results with a new file pattern"? This would mean that maybe I would scan and get all the results possible, then find within those results all the *.txt files, then while I was going through those, I might have been reminded of a *.mob file that I would also need to recover, so then I would want to search for that (hopefully without needing to rescan the entire drive again). This would be a great option, even if it took a long time (long time being even 25% of the time it took to do the initial scan). Another way this might be accomplished would be to have a "file type" field that can be clicked on to resort the displayed results such that they could be viewed in file extension alpha order and sub-sorted by the name (or any 2nd field the user selects). ---- If you're uninterested in adding such an option, is the source code available by chance? I would be willing to add the option myself for my own personal use... Thank you!
  7. I also am having a problem with running into CRC errors and Recuva aborting because of it. I thought the errors were spawned because I had a failing RAM module (since replaced), so I ran chkdsk d: /r /x Part of the resulting output is: Free space verification is complete. Adding 160 bad clusters to the Bad Clusters File. Correcting errors in the Volume Bitmap. Windows has made corrections to the file system. 976759528 KB total disk space. 0 KB in 1 files. 4 KB in 9 indexes. 640 KB in bad sectors. 95796 KB in use by the system. 65536 KB occupied by the log file. 976663088 KB available on disk. Since I'd assumed that the CRC errors were actually introduced as a soft failure caused by the failing RAM module, I figured this would resolve my problem. Since then, I've run Recuva on the drive again, and it again failed with a CRC error (though, far later). Since I don't want to get stuck in a loop of running chkdsk to rewrite/mark bad sectors and then have more appear as I run Recuva across the drive, would it be possible to have an option in the Options settings such that you could have Recuva continue after ALL errors, but log them and let you know what files were affected? Oh, I should mention that this process takes many hours for just chkdsk (and even longer for Recuva)... This is a 1TB drive! Thank you for your help! ---- Edited ---- Additional information. I ran chkdsk again, and found no problems, but Recuva is still reporting a CRC error and aborting. The debug log file is extensive, 4.4GB uncompressed, 3MB compressed... Where can I send it? (or do you want t clipping of just the start and end pieces of it?)
×
×
  • Create New...