Jump to content
CCleaner Community Forums


  • Content Count

  • Joined

Everything posted by Augeas

  1. This is phemonenally long for (I have to disagree with Nergal) what is nowdays such a small drive. I have a 256 gb drive with 80+ gb free and a very old PC and a deep scan takes about 40 minutes. So a 500 gb drive should take - lets be very generous - three hours or so. The USB connection will probably slow the process down, but I don't know by how much. Not six days, that's taking the micky. I don't know what Recuva is doing internally, it should be reading each unused cluster and searching for a recognisable file header, then building some sort of tables in memory. That's not too onerous. It seems that for some drives, or some conditions of a drive, it gets into a loop. Can it really do mass multiple reads on many clusters before moving on? Maybe, but six days?
  2. I am now seeing the slim version (along with the installer and portable) on the builds page via both the http and https urls. Hopefully this has now been resolved. But it begs the question posited by the O/P in this thread, why is the builds page effectively hidden, as there is no link to it from Piriform's site?
  3. H, yes, on first try the direct link to the slim version opened a pure white page and a separate download box (don't know what the tech name is for them) for the slim version. Now all I get is a blank page.
  4. The builds page opens but does not show the slim version. When I first tried the direct link to the slim version 30 mins ago a blank page opened along with a download box which seemed to be fine. Now when I try it again all I get is a blank page.
  5. Well, I've refreshed (ctl-F5) the builds page, run CC, restarted my pc, turned Defender off and on, and still no slim version in sight.
  6. Good Heavens no. Do you see the slim version on the builds page?
  7. I've just tried my link again as in post 4 and it works fine. If the download is location or virus checker dependent then why did I download it OK, then not OK, then OK again?
  8. Recuva recovers files to wherever you specify. It will not replace them where they were. They should be recovered to a separate folder on a different drive from the source drive.
  9. That's strange. It quite quickly diverts to https://www.ccleaner.com/ now, but it didn't when I posted the above. I downloaded the slim version quite easily. In fact I played with the url and replaced slim with portable, and that worked and still works (but for how long, I wonder?). I also wonder if someone is working late at Piriform. These url's are timing out now. I don't know what's going on. I just wish Piriform would say what they're doing and put an end to all this nonsense.
  10. Try https://www.ccleaner.com/ccleaner/download/slim
  11. Yes, encrypt the file. There are plenty of free encryption applications available. I use TrueCrypt for my password file, which - despite it's abandonment by the developers recently - is still uncrackable by any normal means and is easy to use. Easier than all this copying, editing, printing, writing to dvd, deleting, wiping free space, and you're still ending up with a printed copy, the most insecure security.
  12. Files can't be renamed before recovery. Just reciover them to a new separate folder on a different device, and all will be safe. You can then rename them to your heart's content.
  13. It's difficult to see how that occurs. A deep scan will look at deleted clusters until a known file signature is found, then recover the following clusters until another file signature, or a live file, or some end of file indicator, is found. In theory there's no way a sequence of clusters greater than the free space on the disk can be requested. So if that's the message you're getting then I'm out of ideas.
  14. Deep scan runa a normal scan first, so tis might be the big files you are finding and having the same space problem with. Deep Scan files have a numerical file name, such as [01234].ext. They will only be one extent and should not give any problem with space (i.e. they will require just as much as there are clusters i the extent). Look for these file names with large sizes (sort the size column).
  15. Files found with a deep scan will have names as [01234].ext. They will not have their proper file names nor will they be able to be sorted into folder order, as this information comes from the MFT, which a deep scan more or less bypasses. Are you SOL? If I knew what that meant I might be able to guess. I'm quite confused by 'I don't need anything I deleted'.
  16. Do you mean that Wipe Free Space in Cleaner is checked? If so, then a drive has to be selected in Options/Settings for this to come into effect. The default for this is WFS unchecked and no drive checked. If you mean that a drive is checked in Options/Settings then WFS in Cleaner has to checked for this to be effective. As the defaults are unchecked then if both are checked then at some time some human intervention was required to make the change. Yes, wiping free space takes a lot of time, and produces an operation complete message. As your run times are about four minutes then I very much doubt that WFS is running. My normal cleaning run staggers a little at 46 seconds, but is over in around ten seconds or so. That cleans around 2-300 mb on average.
  17. There is no size limitation as far as I know. However when a file larger than 4gb is deleted in an NTFS system then there are changes to the file's record in the MFT. The file size and end cluster number are set to zeroes/FF's. If the file is in many extents then any extension records in the MFT will have the data cluster addresses set to zero/FF's. This causes the not-quite-accurate error message. These 4k+ files are to all intents and purposes unrecoverable. They may still exist on the storage device but unless they are in one single extent then patching multiple extents together is impossible without professional help. A deep scan will show whether there are files of 20gb+ found. If so then recover those and see what you have. Otherwise it's back to the previous paragraph.
  18. Regular old ASCII only suports Latin characters, and half the world uses some other script. I'm no expert, but to quote Wikip ' UTF-16 is used for text in the OS API in Microsoft Windows 2000 onwards', and ' UTF-16 is the native internal representation of text in the Microsoft Windows NT', which is the same thing I guess. So UTF-16 is what Windows uses. The duplicate file txt output has a byte order marker of FF FE indicating that it is little endian. Wikip again '... the application is expected to figure out what encoding to use when reading text data.' The duplicate file txt output is openable by Notepad, which reads the byte order marker amd interprets accordingly. I don't know why Cygwin can't do the same. I think that the bug lies with an application with a name beginning with one C.
  19. Driove Wiper will delete these files when it's finished. It's the way that wiping a drive works.
  20. Although you ran a deep scan the info (very handy, I wish everyone would do this) shows details returned by a normal scan (Recuva runs a normal scan before a deep scan). A file found during a deep scan has no file or folder name, and only one primary extent. The info here is taken from the entry in the MFT. The file header seems to have the correct four-byte signature for an MKV file. I can't say whether the rest is valid, but I would assume that if the file signature is intact then it's likely that the rest of that cluster is intact also. But I could be wrong, of course. There are enough clusters to make up 3gb too. The file header comes from the start of the first data cluster. With TRIM enabled the deleted data clusters should have been cleared. Is TRIM enabled on this drive? Apart from that I'm running out of ideas. After around byte 140 or so the header is zeroes. Is this relevant? Is the rest of the file like this? I don't know. Ultimately Recuva will just recover - copy in other words - whatever is in the allocated clusters, so there's no tweak to do it any better.
  21. Safe? Well, it's very unlikely that you will die. It is however pointless as you cannot physically overwrite a nand flash page. You will also force the SSD to do a huge and unecessary amount of page writes and deletions, which is a waste of time, electricity and a little bit of the SSD's life. That's why you are getting the warning. With TRIM enabled you should find very few deleted files using, for instance, Recuva. Those that are found will be mainly small files held in the MFT, which wipe free space will not remove anyway. A far better process it to run an occasional defrag Optimise, which will TRIM any deleted pages it finds.
  22. Is it the system drive you're recovering from? Is it NTFS or FAT32? Recuva can search for non-deleted files if the option to do so is checked. Recuva can also overwrite deleted files if specically asked. It does not erase anything when it's closed, and will never overwrite live files, even if you asked it to. If the drive is NTFS then the excellent files should open, in the main. How many files do not open (empty boxes, as you say)? Files marked as excellent can be corrupted, if (for instance) a temporary file is written on top of the deleted clusters and that file then deleted. After three days I would not expect this to apply to many files. But if it's the system drive and a lot of browsing has taken place then I suppose it's possible.
  23. 1) You an recover the files to anywhere you want, except the 'source' drive. Recovered files are copies of what's on the source drive. I'm not sure what you mean by ' is there nothing at all on the drive that I was trying to recover?'. All the found files come from the source drive (the drive you're trying to 'recover'). 2) No. Recover the files and then decide which are to be reinstated on the source drive. Well, that's the correct advice, but as you're recovering a backup drive you could recover all to your recovery drive, recreate the partitions on your backup drive, and then replace your recovered files. The problem with this is that you will be reinstating a lot of junk along with the good stuff. 3) Yes - ish. In Recuva Advanced Mode select Options/Actions/Restore folder structure. However this will not work with files found with a deep scan that have a number instead of a name, as they hold no folder information. If you have a list of file names then these should be in folder order, if that is possible. 4) Perhaps. In Advanced Mode Options/Actions check Scan for Non-Deletred Files. This might, just might, give you better results. Try it without a deep scan as it is vastly faster that way.
  • Create New...