Jump to content
CCleaner Community Forums

Augeas

Moderators
  • Content Count

    4,298
  • Joined

Everything posted by Augeas

  1. If I could clarify, a TRIM'd file can be recovered, but will contain zeroes (which as far as Recuva is concerned is valid data). The deleted file's entry in the MFT will still contain the file's cluster addresses, and although those clusters have been Trimmed they will still return a page of zeroes when read. 'Just to see what the recovered files look like, I opened "recovered" number one. Empty. Nothing there. Zero. No recovered files.' Initially I read this as there were no files in the Recovery folder. But reading it again I see that it could mean that there are files there, but with no user content. So the SSD theory could well be correct.
  2. If you mean that the Analyze stage said that it had found 12k+ files then this total includes live files, which presumably you don't want to recover.
  3. There's no data limit on Recuva free or paid. There are still some unresolved questions, is this a flash drive or an USB attached SSD? What version of Windows are you on? If it's an SSD and you are on a late version of Widows then I believe TRIM is, or can be, propogated across the USB connection, and a format with TRIM will wipe the device completely. But don't ask me to confirm this, as I can't. If it's a flash drive (i.e. a flash device plugged directly into the USB port) I don't think that TRIM will be in effect. But again I can't confirm that.
  4. Yes, Recuva works on flash drives. But the question is does Recuva work with USB attached devices? In my experience Recuva works fine in all functions with flash drives directly plugged into a USB port, and with HDD's accessed via a USB attached caddy. So yes, Recuva works with USB attached drives. But from your second post I don't think that that is the problem, the device seems corrupted, which Recuva won't cure.
  5. I don't know about support, except that they probably don't get five stars on Feefo. I can't really suggest a lot. You could try switching your A/V off (disconnect from the internet if you're nervous) and see if that speeds things up. (Before I went to Win 10 I had CC and Recuva excleded from my A/V scans, and it speeded up processing). Your disks are all HDD's, aren't they? I think that Recuva is perhaps meeting its match with the very large drives available nowadays. It works, but there are just too many files. Too many for a human to sort out at the end, as well.
  6. What you are seeing is the file entry in the MFT. The file's data will have been overwritten, If you look in the Info pane in Recuva you will see that the header is all zeroes. When you run a secure delete in Recuva the file status will turn to red, as Recuva knows that it has been overwritten in that session. When you restart Recuva the status will be back to green, as Recuva has no way of knowing that you overwrote the file on the last run, and a file of all zeroes is, or can be, a valid file.
  7. You certainly could try, either the Professional or free version, there is no difference in the recovery capabilities. There are no data limitations with either version, but of course no guarantee that you will receover all, or any, of your previous files.
  8. If what you want to do is to restore a damaged file then neither CCleaner nor Recuva is suitable. CC removes temporary files and Recuva copies deleted files, neither will bring a damaged live file back to undamaged condition.
  9. The concept of secure deletion cannot exist on NAND flash. Secure deletion is a process of overwriting a file's clusters (or pages in SSD terms) and then deleting it. A page on an SSD can't be overwritten, a new page is always used. A normal deletion with TRIM will flag the page as invalid. It cannot be accessed by Windows or any software generally available. A secure deletion, if attempted, will flag the page as invalid, create a new page of zeroes (the overwrite) and then flag that page as invalid (the deletion). So there is no difference between normal and secure deletion, except that secure deletion wastes time and effort and SSD life. Don't use it. If you don't believe me (and you don't have to) run Recuva against your SSD. It will find many deleted file names, as they are held in the MFT, but all the headers will contain zeroes. This is TRIM doing it's work for you.
  10. You could have typed 'seagate ST1000lm035' into Google instead of waiting for one of us to do it. It is SATA and is an HDD. Defraggler identifying it as an SSD is incorrect.
  11. Perhaps you're on an SSD. Perhaps you have something in the file/path box that doesn't match any files found.
  12. Now you're saying something completely different. First you said that a system file was corrupted. What makes you think this? What other people have described this 'scenario'? Now you say that the MFT isn't 'intact'. Of course Recuva assumes an intact MFT, as does Windows and the user, it's the most critical file you will ever find, and the most securely protected. Nobody on this forum knows how Recuva's inner workings actually work, we can only second guess from our own experience. Your understanding of CCleaner is incorrect. CC requests NTFS to delete a file, which it does by flagging the entry in the MFT as deleted. The entry is still there. The 'full edition' acts in exactly the same way. It's NTFS that deletes files, not Recuva. Entries in the MFT are never physically deleted, but flagged as deleted and subseqently reused. I still don't really know what you're trying to achieve.
  13. Yes, but why do you think that this file is corrupt? I think you need someone who is more au fait with repairing Win system files than I am.
  14. What exactly do you mean? Is the file live or deleted? What makes you think it doesn't exist?
  15. Lucien (if you're still with us), files that are marked as overwritten are overwritten by a live file, there is no concept of being overwritten by a deleted file. So your hideous images must be live, somewhere on your disk. Recuva will tell you where they are in the Info pane.
  16. There's no auto stop and restart facility with Recuva. If you are running a recovery (which I understand you are) and not an analyse, you could theoretically stop the recovery, identify what the last file recovered was, and then check the files from that point onwards and run a recovery. But if you are dealing with thousands of files this is likely to be quite a headache to attempt. Your recovery appears to be grindingly slow, and Recuva appears to be doing nothing in the Task Manager snapshot.
  17. Simple question first - are you trying to save the files to the same drive? I've only seen this message (can't find file) on files greater than 4 gb, which I can only see one in your list. Apart from that I can't see why you are getting that message for all the files. A file with a header of zeroes is not a valid file, unless it's a text file of zeroes, so it is not a suitable candidate for recovery.
  18. That link is hardly relevant as it discusses correcting an undeleted file, not recovering a deleted file. Recuva does not alter one bit of the data it recovers, or more correctly copies. Carmella, no software can guarantee to recover a deleted file, it depends entirely on the subsequent activity on the disk. If it is an SSD then forget any hopes of recovery. If it did not appear in the list of found files then it's likely that the entry in the MFT has been overwritten. You could try running a deep scan and looking for .doc or .docx files with a size close to the deleted file. If no file exists with the approx size then it is possible that the file is fragmented. If so it is not possible to recover fragmented files from a deep scan with Recuva. Windows updates deleting user files seems very peculiar to me, perhaps someone with more knowledge on this can comment.
  19. No. It's an SSD and on formatting a global TRIM is run resulting in a squeky clean storage device.
  20. What do you mean by unable to recover? Did you find the deleted file? Did you attempt to recover it and failed? Didi you recover it and the contents were not what you expected? How did you delete the file in the first place?
  21. I'm not sure what you mean there. If you plough through http://kcall.co.uk/ssd/index.html it will give me time to go to bed.
  22. That's right, the O/S and the SSD controller will treat the writing of a new file to 'deleted' pages as an update of the pages. By their nature SSDs run with most of their deleted and TRIMed pages unerased, the SSD is shall we say full, even if the O/S only shows live data. Garbage collection is done nowadays i the foreground as it reduces the number of extraneous writes and also lessens the load on portable devices. I don't know how the SSD controller can know that pages are no longer used by the O/S's file system. That info is held in the MFT and cluster bit map which the SSD can't read.
  23. A zero fill would use zeroes from the user's point of view, which is greatly abstracted from the actual values written to flash cells. If the SSD is quite old (10 years +) then it might not support TRIM, in which case a very infrequent WFS might be beneficial. If nothing is done then there is no way for the SSD controller to know which pages have been deleted by the O/S. When a page deleted by the O/S is subsequently reused the SSD's garbage collector will flag that page as invalid and use a previously erased page. You may have to wait a few micro-seconds in this case. This is how USB flash drives work as USB doesn't (or didn't until very recently) support SATA protocol.
  24. I don't use Defraggler so I don't know what options it has but don't you mean CCleaner? Whatever s/w it is the process of writing a file and then deleting it is totally different from erasing a NAND flash block. The SSD's grabage collection routines will erase the (invalid) block irrespective of what has been written there previously. And don't bother to zero or anthing fill an SSD. Windows will not allow you to access TRIMed data, and the block erasure will remove anything that was written before permanently, so a normal delete will do.
×
×
  • Create New...