Jump to content
CCleaner Community Forums


  • Content Count

  • Joined

Posts posted by Augeas

  1. Ahh, I missed the bit about it being an SSD. Your chances of recovering file data from and SSD are close to zero.

    Cancel stage 2 as soon as stage 1 ends.

    Forget the $I file, the $R holds the data.

    Whatever you've found look at the header data in the Info pane in Advanced mode.It's likley to be all zeroes. It is almost impossible to recover data from a modern SSD.

  2. Well I don't know everything. Consider that 6.6 gb is only 0.0066 of a terabyte, so it could just be rounding (e.g 1.814 less 0.006 = 1.808 rounded to 1.81).

    Using properties on the drive will give a more accurate figure.

  3. Possibly because drives are specified in terabytes (1k = 1,000 bytes) and Explorer uses tebibytes where 1k = 1024 bytes. So your 2tb disk says 2 terabytes on the label and 1.8 tebibytes when examined by Explorer. It's actually 10 to the power of 12.

    You will have some relatively small system files on there after formatting, but who knows what your 'some files' means.

  4. I guess there's a message under the pics.

    The first pic quite simply says that none of the files found matches the search criterion. No file having that (what looks like a) folder name was found.

    Running a deep scan as seemingly recommended is futile, as files found with a deep scan have no file or folder names associated with them, as they are held in the MFT and a deep scan does not look at the MFT so cannot use anything in the search box.

    If the search criterion is correct then unfortunately there's nothing to be found.

  5. I don't think that that information is held in the MFT record. There is a file created and file modified date field, and a MFT modified date field, but I don't know if the latter is updated on file deletion. Whether or not Recuva doesn't show it.

  6. I don't think that Windows allows FAT32 partitions greater than 32 gb, how large was the partition on the 1 tb disk? How did you get Recuva to recognise the remaining part of the disk? Recuva requires a drive letter to function.

    But the crux is that without a file system Recuva won't be able to do anything. Don't let that stop you trying the various options, scan for non-deleted files etc. You might be lucky, and it's something to do on Christmas Day when the TV is rubbish.

  7. Recuva will list all the deleted file records in the Master File Table. If they're not listed then they're most likely not there. Deleted file records are reused generally in the lowest-numbered record found order, which is why files created and deleted on the same day are likely to be the first to have their MFT records overwritten.

    Nobody knows what user and system activity is going on on your pc.

    If the file names aren't in the MFT then they won't be found elsewhere.

    Unless your packet capture files are in some common format (doc etc) then a deep scan won't find them, and is pointless.

    I don't use the recycler, so I can't answer your question.

  8. I've only had experience with relatively small drives, 500 gb and under, and a deep scan takes about 45 mins at the most. Some people do experience very long scan times, and yours seems exceptionally long. I have no idea what the cause is, or what Recuva is trying to do.

    I usually cancel at stage two and I have never found any detrimental effect, the files found are still displayed. You may wish to try that.

    I also have Truecrypt containers and they do not slow processing down. To Recuva they are files with a name and a cluster allocation, just like any other file. There is no indication to anyone that they are encrypted.

    USB access will probably slow things down a little, but a month is ridiculous.

  9. Files sent to the recycler are renamed to $Irandom.ext and $Rrandom.ext. The $R files are the data, the $I files hold the file name etc.

    As you have created and deleted the files on the same day it is very likely that the MFT records have been overwritten by later activity, as they are reused on a first available record basis.

    Deep scan looks for a specific set of file headers. You describe the files as packet captures: I don't know what they are but unless they fit into the list scanned by Recuva (look at the drop-dpwn list in the File/Path box) themn a deep scan will not find them.

  10. You won't find any folders as Recuva does not recover folders explicitly. Deleted directories contain names of files that don't necessarily exist, and index array offsets that are clearly invalid.

    I don't know why you can't find any files, I can't either. A scan of my disk reveals about 20 files from the documents folder, none of any use. Perhaps Win 10 behaves differntly from its predecessors.

  11. That's the fundamental difference between CC's secure delete and Recuva's. CC can legitimately rename a file because it is still live, but Recuva can't because the file is deleted and its MFT record is inaccessible. Also small files, under 700 bytes or so, can be contained wholly within the MFT so remain in their entirety.

    What is wanted is an independent MFT wiper, with random lower case file names instead of those ugly ZZZ capitals. You can of course build your own MFT wiper. Create a folder on a flash drive with sub-folders holding say 20 files with random names and a few bytes of data. Duplicate the sub-folders until you have a few thousand files. Just copy the lot to your drive, and  then delete them. If you do that all your incriminating file names and contents will have gone.

    Surprisingly since I went to Win 10 I can find hardly any user files with Recuva. It's as if constant updates are overwriting the deleted user data files. Perhaps they are.


  12. I was thinking more about whether the USB software supported the TRIM command. TRIM is a SATA command, and USB protocal isn't. I have read that later USB software can support TRIM, but it's all a bit hazy. TRIM is becoming less relevant now, as the trend in SSDs is towards foreground garbage collection.

  13. 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.

  14. 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.

  15. 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.



  16. 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.

  17. 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.

  • Create New...