Jump to content
CCleaner Community Forums


  • Content Count

  • Joined

Community Reputation

1 Neutral

About Augeas

  • Rank

Profile Information

  • Gender
    Not Telling
  • Location
    Where Stuff is made, UK

Recent Profile Visitors

4,731 profile views
  1. Well, this is heresy, but here goes: Remove the multiple pass overwrite option on secure file deletion and Drive Wiper, leaving one zero-byte pass only, saving decades of lost time and tons of CO2 in wasted energy. Surprisingly for a tech and science dominated field, the multipass myth has achieved unquestionable god-like status. It was thoroughly debunked over twenty years ago. Chances of being adopted - close to zero.
  2. The Ignored Files includes live files, zero-byte files, system files etc, which you would not normally want to recover. Also if there is any file name or path in the aptly named Filename or Path box then this will restrict the results, possibly down to zero. The free and paid version have the same recovery facilities.
  3. If by 'Exited the list' you mean closed the program, yes, you will have to do a rerun. If you mean that you have, for example, typed a search word in the File/Path box, then clearing that should restore the original list. Scan results are held in memory to avoid overwriting data, so when the program closes the results are gone. If your storage device is an SSD then post back here first.
  4. Google it, and you will know as much as I do.
  5. How should I know? I doubt if it was supported years ago as 64k+ clusters were only introduced in NTFS in late 2017. Why not try Windows defragger?
  6. This seems to indicate that not much supports clusters over 64k, at the time it was written. It seems a pretty serious change. https://dfir.ru/2019/04/23/ntfs-large-clusters/ And the About Defraggler page states that defragging NTFS clusters greater than 64k isn't supported. https://support.piriform.com/hc/en-us/articles/360048065892-What-Defraggler-can-and-can-t-do
  7. Good to hear that copies come to the rescue. As for disabling TRIM, that advice sounds as if you disable TRIM after discovering that files have been accidentally deleted. This would be ineffective as TRIM is an asynchronous command issued on file deletion and disabling it afterwards is shutting the stable door when the nag has well and truly galloped off down the road. For this method to work you'd have to have TRIM disabled permanently, which is possible if not recommended (although I'm not fully convinced of it's worth these days).
  8. It's (probably) due to the way the SSD controller handles deletes, NAND flash architecture, and Windows TRIM for a start. When a page is deleted TRIM notifies the controller and the controller unmaps the page. Any reads of that page, as Recuva will do when if follows the cluster run addresses held in the MFT, will return a default page, commonly of zeroes or less commonly random data. Look up DZAT and DRAT on Google. In the real world deleted data on an SSD has gone forever. The unmapped page is in limbo, and is wiped, sooner or later, by the SSD Garbage Collection process. Perhaps, just
  9. If the drive is an SSD then you're unlikely to recover any valid data, although what you do recover should contain zeroes not a hex char. If the O/S is FAT32 then the file cluster addresses are modified on deletion, so that they point to a different, and incorrect, cluster. Recovery is again unlikely.
  10. Yes, it all depends on what the OP means. In my experience if Recuva can list a file then it can - in general - recover it. Exceptions (that I can think of) are if the file is zero bytes in length, or the cluster addresses are invalid, or it's a live file that's locked for some reason. In each case there should be an error message. If the recovery is from an SSD then the files can be recovered, but will contain zeroes, which might be what the OP means.
  11. Of course the MFT was recreated during the format, that's what a format does. The MFT should contain about 20 or so system files and nothing else. A deep scan will not return any directory information, as this is held in the MFT. You would be better off running a normal scan with Scan for Non-Deleted Files checked. This is fast and, if successful, will return much of what you want.
  12. It's certainly going to make recovery difficult. Did you check Scan for Non-Deleted Files? If so these files - with file names and directory info - will be worthless, as the cluster addresses are multiples of block sizes, the wrong block size. You need to look at the deep scan files, those with just a number and extension. Assuming the sector alignment is the same (i.e. both block sizes start at the same boundary) then you may possibly find and recover some files. But you will be retrieving two 16k blocks in one 32k read. Whether this is valid, and for all file types, I don't know. Also y
  13. I don't think that a deep scan will be fruitful as the file extension - unity - is not, as far as I know - one that is interpreted by a deep scan. Data not found on disk means that the file's data cluster address fields do not contain valid addresses. It is not easy to say why this has happened. It may be because the files were in a lot of extents.
  14. You could also try Explorer, right click drive, select Disk Cleanup, Cleanup System Files. Windows Update Cleanup will be first on the list, and if you check that and run Cleanup you should save several gbs.
  • Create New...