Jump to content
CCleaner Community Forums


  • Content Count

  • Joined

Posts posted by Augeas

  1. The ignored file count  is non-deleted files, zero length files, etc. If you are using an SSD then a deep scan is likely to find nothing. If you have some search criteria in  the File/Path box then it is possible that no file fits that criteria.

  2. Microsoft does update its documents. Despite my earlier post (does anyone actually read what I post?) Trium's extensive cut and paste concerns XP and Server 2003, and Eddy's link harks back to 2004. If you really want to know about the Set MftZone parameter of Fsutil in Windows 10 then look at  https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-behavior 

     But all this is a distraction. The MFT Zone is a mythical, OK logical, area of disk space which is kept clear for MFT expansion. I can't see what it has to do with wipe free space speed. The MFT remains unchanged, the same bits in the same position, whatever the Zone parameter is.

    An MFT wipe is a rather crude 'fill the empty records with files and then delete them' process. I would hope that CC would calculate the number of empty MFT records, allocate the same number of small files (I think it's abour 650 bytes) and then delete them. That file size is used as it does not require a cluster allocation, and it is large enough to ensure that the previous contents of the 1024 byte record are overwritten. The process is simple: CC allocates a number of small files: NTFS scans the MFT and reuses the free records. There is some directory maintenance - those new files have to go into a directory somewhere - and this could be complex if the number of free records is considerable. That number is likely to be in the tens of thousands. Does CC use one directory or multiple directories? I don't know. Furthermore directory names are held in ascending order, so if the new files are named in a way that is anything but an ascending sequence, for each file allocation all the directory entries will have to be moved down one place to fit the new filename in. An ascending file name will go on the end of the long name chain with minimum distruption. A descending file name will be a killer, with extensive updates through a chain of thousands of files.

    Does this cause the slowing down of WFS? Quite possibly, I really don't know.





  3. The Restore Folder Structure applies to recovery. You can rerun the scan (if you have closd Recuva), check the Restore Folder Structure box, and then recover whatever you select to a separate drive. The recovered files will have the folder structure as far as can be established. You can then copy what you want back to your C drive.

  4. As I undestand it the shadow copy system uses some sort of versioning method so that only changes to a file are stored. It may not be possible to recover complete files with Recuva from the shadow copies.

  5. If you open the files with Notepad, or look at the header in Recuva, the file should start with %PDF-1.4 or 1.5. If there is no %PDF at the start then it's most likely that the data isn't a pdf and won't contain your data. I assume the disk is NTFS?

  6. It's abnormal. I can run a deep scan on a 256mb SD card in (I guess, haven't run one recently) around half an hour, and that's with the card still in the camera attached by usb. So a 500mb card should be done in an hour or two at the most. I guess the timing depends on many things, not least how the card became corrupted. Also Recuva seems to have a habit of nodding off, if not actually sleeping. I don't know what it's doing.


  7. I think that the first batch of files found is the normal scan which a deep scan runs first, zipping through the MFT. However a deep scan has to look at and anaylse every unallocated cluster. Three tb is huge, and at 4096-byte clusters it would take 8.5 days even if it could anaylse 1,000 clusters a second, and it's probably processing at a far lower rate than that. Being USB connected will slow it down as well. These disks are just too large to backup, too large to recover.

  8. 1) the other settings you mention do not apply to WFS, they are in the section for Secure Delete, so the answer is no. With native WFS you get one pass of zeroes.

    2) Wiping Alternate data streams and cluster tips are irrelevant in WFS, whether using Drive Wiper or the native WFS. The action of wiping MFT records is done under the control of NTFS, but effectively the whole record is wiped, by which I mean overwritten. Wipe MFT uses a single overwrite. Normal or secure doesn't make sense, the data is being overwritten.

    Yes, the documentation could be better. No, I am not going to do it.



  9. 7 hours ago, Edward5932 said:

    This is exactly the problem.  Wipe Free Space DOES wipe the MFT when this option is unchecked in Options/Settings.


    I think you may be confusing the two processes, which are entirely separate. Unchecking the Wipe MFT box in Options/Settings only applies when you run Wipe Free Space from Cleaner/Windows/Advanced. Using Drive Wiper will wipe the MFT whatever is in the Options/Settings box.

    If you don't want the MFT to be wiped then use WFS from Cleaner/Windows/Advanced.

  10. All you can do is try a larger drive. Are you trying to recover system files, some of which are sparse files with a nominal size of the disk?

    Usually with an SSD it is impossible to recover any file after a format, as that runs a universal TRIM. If Recuva is listing files than perhaps TRIM isn't working across the USB connection. Try a recovery and see what you get.

    Oh yes, you can restore the folder structure (as much as you can) by going into Advanced Mode, selecting Options/Actions, and checking Restore Folder Structure.

  • Create New...