Jump to content
CCleaner Community Forums


  • Content Count

  • Joined

Everything posted by Augeas

  1. By deleting unused space I assume you mean wipe free space? Don't run Wipe Free Space or Secure File Deletion on an SSD. If TRIM is enabled (i.e you didn't get your pc from a museum) then it will perform the same function as WFS and SD. Occasionally run a Defrag Optimise to clear up any TRIM commands that have not been executed. You can run the normal CC functions - deleting unwanted files etc - as usual.
  2. I’ve removed your link to a competitor product as this is an official Piriform forum: if anyone is interested they will be able to find it easily enough. And whilst we’re talking about the competition, that product is only 291 kb. Oh for the days when CC was well under 1 mb, long gone now. CC has always done more than file deletion, but it is a bit of a porker now (es ist ein bisschen fett). It all depends on the mechanics of the deletion. A folder with 100,000 entries is huge, with hundreds, if not thousands, of MFT records and many index clusters. For secure deletion CC must: Open each file Overwrite the data Save the file Rename the file Delete the file Every time a file is renamed its position in the huge list of files in the folder is altered. Files are stored in the folder in alphabetic sequence, and when the file is renamed (to a variant of ZZZ.ZZZ) the sequence must be shuffled up or down to accommodate this. If CC overwrites, renames and deletes the files in reverse alphabetic order (last file first) then only a few MFT records have to be rewritten every time a single file is deleted. If it processes the files in a different order, or a different manner, then there’s a huge amount of work to be done. On the other hand finding the last file in a huge folder is onerous. Every entry for each file has to be read until the EOF is found. And if the last file is edited, renamed and deleted, is position lost so that the last file has to be sought from the start again? It would be easier to delete the first file first, but the renaming would be a nightmare for performance. Is this what is happening? We can add to all this writing entries to the log journal, updating the MFT index clusters, altering the cluster and MFT bitmaps for every file deleted, and syncing the disk every few seconds. And things I haven’t thought of. It’s a wonder really that the process ever finishes. I don’t know what the opposing software does, but this list (apart from the editing and renaming) is what NTFS has to do to delete files from a folder, whatever software is used. Perhaps CC doesn’t use the most efficient way of securely deleting the files, and it is only exposed on folders with a very, very large number of files. You could be better off if you normal deleted the folder and then ran a wipe free space. The overwriting pattern doesn’t matter by the way, it’s all randomised before being written to the disk.
  3. A new version? You're respondong to a six-year-old thread, is anyone still running a six-year-old version of Defraggler? I doubt whether the posters are still hanging on for a response, or even still have the same hardware.
  4. Could be associated with constant delivery network, have a look at https://forums.opensuse.org/showthread.php/504803-s-uicdn-com That;s the extent of my knowledge, which was non-existant until I opened Google a few mins ago.
  5. Er, Options, Cookies, move those you wish to keep from left to right pane.
  6. Maybe it isn't that dumb. Some 30 years ago when I was a sysprog on IBM mainframes the space search algorithm was (wherever the write heads were) same track, same cylinder, one cylinder either side, three cylinders either side, give up and go to the start. I would not be at all surprised if NTFS didn't do something similar. If there were no algorithm then files would just be written from the start of the device, or somewhere similar. Maybe they are. As for moving the MFT, that is onerous, and would need a rewrite of the VBR, MFT internal records, and the MFT mirror, for no great advantage. The separate zones of the MFT (it is allocated in blocks of 200mb) can be defragged into one continuous extent but I don't think that the position of the first records of the MFT can be moved. My memory is getting rusty on this though.
  7. True, but there again nobody knows how NTFS allocates space for files (and believe me, I have looked).
  8. It's already there. Just let Avast A/V install itself when you install CC. An A/V is not - generally - something you run every few days or so when you feel like it, it is permanently active. You could ask why doesn't the A/V include CC? I suppose it could, but not on my machine.
  9. Not according to my knowledge and experience. There is a setting in Advanced Mode that enables Recuva to show non-deleted files, but they have a status of Non-Deleted. What makes you think that you have live files listed?
  10. The peculiar thing about fragmentation, and defraggers, is that you never actually look at the storage device in any detail. The cluster map is created entirely from the Master File Table and the Cluster Bitmap (and perhaps a few other meta data bits) - it's a logical construct created by defraggers who, after loading those two files, don't need to access the drive at all. Fragmentation, or the lack of it, is defined in the MFT, not at the disk level. It's another logical construct created by the Windows File Manager NTFS. Files too are logical constructs existing soley in the mind of the MFT. The storage device knows nothing of files, folders, fragmentation or free space. The disk doesn't defrag itself. It can't, for the reasons given above. If it did then you would never be able to access a file again through the MFT.
  11. I don't think that you are, or could be, physically prevented from doing what you like whilst a deep scan is running, but as the scan is very heavy on I/O any response might be so slow that you would get the impression that the device is locked. You are also altering what Recuva is scanning, with the possibility of damaging what you are attempting to recover, so it's not usual practice.
  12. This message usually comes up when the deleted file is large, in excess of 4gb. When files of that size are deleted NTFS zaps the cluster addresses, so the data can't be found. Although the data may still exist on the disk it will be extremely difficult to recover. A deep scan should find the first extent, under a generated numerical name, but the other extents can't be identified without professional help.
  13. You cannot remove the file name from the MFT with Recuva. You can overwrite the file's clusters but the file name will remain. If you Wipe Free Space with Drive Wiper in Ccleaner it will overwrite all the deleted file names. Perhaps you could try this.
  14. Augeas

    Drive Wiper

    It will never 'remove Windows' as it runs under Windows. It can, however, wipe a non-system drive completely whatever it previously contained.
  15. In Advanced Mode enter all or part of the file name in the File Name/Path box. Or you can click on the various columns to sort in order.
  16. It won't make Recuva run any faster (it still has to scan every cluster on the disk) but 15 hours is horrendous. After running a wfs a deep scan should find very few files. It will still show all the files in the MFT as these can't be removed. They should have invalid names though. If Recuva finds 175,000 deleted files then this is the amount of deleted files in the MFT. If this is the number reported as ignored than they are undeleted (live) files from the MFT.
  17. Wouldn't it be easier to run CCleaner before a defrag?
  18. I think that running in adbvanced mode gives more flexibility and control, but it won't give greater search or recover facilities. Recuva will, at the end of a scan, show files found and files ignored. The ignored files are live, zero length, or system files etc. You can show these by switching to advanced mode and then checking the relevant boxes in Options/Settings.
  19. I guess you're running the wizard? I've never seen this message, but I don't run the wizard very often. Perhaps it's the selection choices for the source data. This message came after the scan? Recuva does not recover any files during a scan.
  20. Because it's a suggestion, not a query. Because it's in the Defraggler Suggestions forum. Because moderators can't change any Piriform code or policy. Because it's not something we either like or dislike. Because we're not in the pay of Piriform. Because we don't know whether Piriform will act on this or not, or when. Because we only reply when we can offer something constructive.
  21. Did you wipe free space using Drive Wiper? Drive Wiper overwrites the deleted records in the MFT so Recuva should return a long list of null, or ZZZ.ZZZ file names. All these null files should be a few hundred bytes in size, and be contained in the MFT. There shold be no clusters allocated to them. Are you still seeing the thumbnails? If you are, these should be found with a deep scan, and will have a numerical file name assigned instead of the actual filer name. These will not be overwritten by a live file, and can be securely deleted (which is just another overwrite). If you are seeing the thumbnails, go to the Info panel as described above and post a screenshot of what is there.
  22. Well, it is four and a half years since Idlewild visited, so I don't think he cares one way or the other. The answer to his and your question is in paragraph two of my post. Let's stick to one thread, shall we?
  23. Rob, if you look at any of the forums you will see that 'no one replies to anything' is nonsense, and only aggravates those who do reply. I understand that creating a disk image is a paid-for option, so you are entitled to direct support from Piriform. I have the free version of Recuva so I can't reproduce, or experience, your problem. You say that the screen goes blank, but fails the space calculation. Does it do both? If you're trying to recover a file or files, I would suggest that you don't run the disk image creation whilst there are problems with it.
  24. If you open an existing ExCel spreadsheet a temporary file is created called ~$Filename.xlsx. This is 165 bytes in size. If you open an ExCel file called Invoice #150.xlsx a file of 165 bytes is created called ~$Invoice #150.xlsx. Forget what I said about the recycler, this is (I believe) what you have recovered and are trying to open. I can create such a file and open it easily, so I don't know why you are having any difficulty. However, it isn't the file you want. The empty ExCel file I created to test this is 7.63 kb in size. No valid Excel file is 165 bytes in size. Forget this file, it will get you nowhere. It appears to be left behind after a crash of either ExCel or your pc at some point. You need to search for another ExCel file and. depending on how many you find, recover them to a folder on another drive and then look through them to see if you have found your invoice,. Don't bother with files of 165 bytes.
  25. I presume you can't rename it? The file is 165 bytes in size. I very much doubt that there's anything of use in there. Files sent to the recycler have their names changed to $Innnnnn.ext and $Rnnnnnn.ext. The $I file is an index and was (up to Win 10) 145 bytes in size. Perhaps this is what you have found. The $R component is the actual file data. That's the one you want.
  • Create New...