Jump to content
CCleaner Community Forums


  • Content Count

  • Joined

Everything posted by Augeas

  1. It doesn't matter what the original folder size was, you are finding, and attempting to recover, all deleted pic files. Recuva has found 48 million pic files, even at 1 cluster each that's nearly 200 gb. At ten clusters each, say, that's 2 tb to recover. By the way I have no idea what Recuva writes to memory, apart from everything.
  2. There are a lot of similar cases in the forum and my poor fingers, not to mention my remaining brain cells, shy away from typing the same old stuff again. But, even though goats can be a pain in the backside, here's a brief synopsis: How did you select your files for recovery? Did you have a filter on file name or path? If you did, or the files were zero size, or were system files, or were secureley deleted, Recuva may well have not recovered any successfully. Didn't you get an error message saying why? I'm sure a screen shot (no, not of the goat), would help.
  3. Everything's a partition in Windows, so don't worrry about that. The pic in post 1 shows entries in the MFT after they have been wiped, that is after enough 712-byte files have been allocated to overwrite all the free records in the MFT, and then deleted. Drive Wiper runs a wipe MFT before the wipe free space, so you should have seen a Wiping MFT message first. It's very likely that there will be some 'deleted' records in the MFT, whether ZZ's or other names. That's what you see with a normal scan (and also with a deep scan, as a normal scan is run first). If you don't see any results with a normal scan, then: 1) So many new files have been allocated that the MFT is full and is now creating new records for new file allocations, i.e. there are no deleted records in the MFT. 2) There is something in the file/path filter box in Recuva, and nothing corresponding to this filter is found. 3) The option in Recuva to show securely deleted files is unchecked, and somehow Recuva can identify those ZZ files as securely deleted (maybe a specific file header?). The screenshot in post 4 is confusing, as file and folder names are only held in the MFT, unless Recuva is digging them up from somewhere I am unaware of. I have found a problem with WFS, in that in a drive that has a lot of fragmented free space (although the live files themselves may not be fragmented) some of the smaller space allocations are missed. This might be your case as the file sizes are relatively small. To get rid of them use Recuva's overwrite. This won't get rid ofthe file names, but as I don't know where they're coming from I can't really suggest anything else.
  4. Are you using Drive Wiper or Wipe Free Space from Options/Settings? And what version of CC?
  5. I suppose it is possible for a random set of characters to mimic an flv header, but four times is a bit of a coincidence. You can of course try whatever software you choose, but I think you need professional help, or at least someone knowledgeable who can look at your disk in greater depth than we have here.
  6. In a deep scan Recuva looks for a known file header, and determines the file type from that. It must have found four flv file headers. I've no idea how it determines the file size, possibly reads the following clusters until another known file header is found. Or they might just be big flv files. Why not play them to see what they contain, but don't blame me if you get sacked. There's no way to 'convert' these, they are flv headers. I don't think you'll get any further with Recuva.
  7. Yes, it has been discussed endlessly, mostly by people whose knowledge is, or was, HDD based (and I'm one of those too). We can more or less figure out what happens on a hdd when a wfs is run, but who knows what an SSD controller is doing? As I'm sure you know, a TRIM (or a defrag Optimize) won't get rid of file or folder names and paths, because these are held in the MFT, which will never be trimmed. A wfs using Drive Wiper runs a wipe MFT first, and overwrites the deleted records in the MFT by allocating enough small files to fill all the unused records. This is a ham-fisted way of wiping the MFT as it involves two separate page writes (allocate and deallocate) to the MFT bitmap block, two to the offending MFT file record, and at least two to the owning folder. So a wipe MFT could write thousands of SSD pages, but there is no other method that I or Piriform know of to get rid of those file names. It's a pity that the wipe MFT function is not available separately, as a wfs must be the complete pig-fisted way of wiping the MFT. The actual wipe free space process is superflous to wiping the MFT and a defrag Optimize will do the wfs part far more efficiently than CC's wfs. There's no real answer to your problem, except mine which is to ignore the file names and stop worrying. Who is going to run Recuva on your device to see what files you have deleted? There are so many other things to be paraniod about.
  8. Augeas


    Unrecoverable means that all (or virtually all, I don't know the actual figure) of the file's clusters have been overwritten. Recuva will recover whatever is in those clusters. The recovered file will contain whatever overwrote it, and will be of no use in reconstructing the original deleted file. In advanced mode you can see what clusters have been overwritten, and by what, in the Info pane.
  9. Excellent means that no clusters have been overwritten. The contents of the clusters could be anything, Recuva does not make any judgement on the veracity of the data. What has been recovered is what is on the disk, no more or less. I'm not going to open an unknown excel file, and not everyone has Office, so please post screen shots only.
  10. You can, in Advanced mode, put part or all of the folder name in the File or Path box, and all files identified with that folder will be shown, and can be selected.
  11. It's there in Analyse, but not in run, presumably because there would be little point in it after the file has been deleted. I haven't checked if this is the same on older versions.
  12. Portable 32 bit exec v540 7,817 kb, v541 12,464 kb, 59.5% increase.
  13. I don't think he's saying that it's too large for current storage, but it's very large for what it does. I'm curious to know why the exec size increased by 60% between 540 and 541. That's an awful lot for a few tweaks and a few k of tool tips.
  14. This is your third thread on this subject: once is enough, we can all read quite well. Do you have anything as a search filter? If so remove it. The 23 files may be system files, or zero bytes files, or anything you have checked in the Options/Settings panel. CC, assuming that is what you wiped the drive with, has several methods of overwriting data. A disk erase should leave a clean disk but CC is not a verifiable authenticated disk cleaner.
  15. You can't pause the process, but you could select say one tenth of the files to be recovered and recover them, then another tenth later etc. It is awkward as you will have to keep track of where you are in the process.Disks are getting so large that the recovery process is almost beyond human control, with hundreds of thousands - or more - of recovered files to manage. All files found with a deep scan (those with a [1234] file name) will be marked as excellent by definition, but may not be actually. Recuva can only find the first extent of a file so those with multple extents may well be unusable.
  16. If you overwrote the pics with Recuva as in option 2 above, and can still see the pics, then they must be either small pics held in the MFT (which Recuva can't touch) ot they are live pics that are using the clusters that the deleted files had allocated to them. Bear in mind that we don't know exactly what you are doing nor do we know exactly what Recuca does.
  17. No. Read this.... https://www.ccleaner.com/ccleaner/faq/general/is-it-ok-to-use-ccleaner-in-my-business-or-to-provide-services-to-other-companies
  18. I shouldn't think so. How would it access a sector that couldn't be accessed?
  19. I have never known Recuva to take more than a few minutes at the most with a normal scan. I have just run a normal scan on a file/folder and it took under 14 seconds (on a modest but ancient system).
  20. I've no idea. Do you mean start with "$$_"filename, or $$_filename? Does the folder name give you a clue?
  21. A defrag is bad news. As you know only too well it will utilise any free space it requires to create unfragmented files, and that free space includes the files that were deleted. So a percentage of the deleted files could well be overwritten. A normal scan may find evidence of the deleted files, as their records will still be in the MFT, but the clusters they previously used will quite possibly be overwritten.
  22. The entire disk is being read, not just the old lost data. Two tb is a large drive, about 500 million 4k clusters, each of which has to be read and analysed, and an internal results table built. Unfortunately 18 hours is not an unrealistic time, going from what others have posted.
  23. You could run Defraggler to defrag free space. If you're not a Defraggler user then see how to in the documentation. Then rerun the wipe free space Are you running Drive Wiper?). If you do this then please let me know the results, as it will test a theory of mine. Alternatively run Recuva deep scan then select all/overwrite selected (one pass). This will still leave very small files (under 700 bytes) untouched, as they are held in the MFT. This is a bit of a sledgehammer solution.
  24. No, the filter applies only to the results of the scan, the scan will still take the same time as all sectors have to be scanned. You don't say what the capacity of your drive is, if it is huge then a deep scan will take some time. Eight hours is not particularly long. It might be just me, but perhaps a backup of data before doing a system install would be circumspect.
  25. 1) Is this disk included in Windows' regular defrags? I don't know if usb connected devices are included but it's worth checking. Plus things I can't think of or don't know about. 2) I think that it's safe to say that a device withour power or means of access will be safe from modification, except by Martian death rays. If it is connected then it could be modified. I'm not saying that it will be, but nobody can say for sure that it won't. 3) More or less the same answer as 2. Not as far as I know. Maybe there is some error checking done or logs written somewhere. 4) A normal scan is very fast and reads the MFT, not the disk. A deep scan takes far longer and reads each unallocated cluster. It is advantageous if you can recover your files from a normal scan, they will be complete and up to date, one hopes. A deep scan does not retrieve file names or secondary extents, only selects a small range of file types, and does not differentiate between files days or years old. And takes ages to run. 5) A recovery - as long as you are recovering to a different device - should not harm the files nor degrade any future recovery attempts. It is a read process.
  • Create New...