Jump to content
Piriform Community Forums


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

1 Follower

About Augeas

  • Rank

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
    Not Telling
  • Location
    Where Stuff is made, UK

Recent Profile Visitors

1,758 profile views
  1. 5 files found, can't recover

    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.
  2. 5 files found, can't recover

    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.
  3. 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.
  4. Recuva won't delete thumbnails

    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.
  5. Where is the path C:\?\

    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?
  6. 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.
  7. File recovery not working

    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.
  8. File recovery not working

    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.
  9. The larger disks get, the more difficult it is for both recovery software and the poor person handling the recovery to manage such large amounts of data. Whilst a pause or save facility might seem a good idea it brings the problems that if the pc is being used then the underlying data is being changed, it would taks some time to reload or locate previously found data, and worse of all Recuva would have to write a fair amount of data to the disk, which is something that it tries very hard not to do, as this can destroy what's trying to be recovered. Files can't be reconstructed or recovered in place. The complexities of modifying MFT records, MFT bit map, cluster bitmap, folder entries, and clusters (even assuming that they were still available for resurrection, would be horrendous. Add MFT extension records, index records etc and it's even worse. NTFS does not allow anyone to touch system metafiles either. Recovery to another device is just, well, safer by far.
  10. Recuva Slo-o-ow. Never used to be

    Recuva hasn't been updated for yonks, mine is dated Feb 2017, so it's not somethiong that has changed in Recuva. 1) Don't know 2) Who knows what it's doing? 3) Run a wipe free space with Drive Wiper. Recuva will probably still take as long but you won't get the huge list of found files.
  11. SSD Optimization

    It probably has no, or very little, effect on the lifespan of the device. A retrim (which is what an SSD optimise is) will issue the same TRIM command to pages already trimmed, as NTFS - which issues the TRIM and retrim commands - has no knowledge of what pages have already been trimmed. I would imagine that the SSD controller would recognise that a page has already been trimmed and ignore the retrim command for that page. A cluster which has had a successful TRIM executed against it does not have a physical page allocated to it so it's difficult to see how it could be trimmed a second time. I've used the words probably and imagine as nobody here knows how the propietary software in SSD controllers works at this level of detail.
  12. Recuva won't delete thumbnails

    It isn't easy to describe a problem and it certainly isn't easy to diagnose one from a distance. It would help if you could answer the questions asked: Is the file system FAT32 or NTFS? In Recuva Advanced mode select one of the thumbnailed files and in the info panel on the right: How many clusters are allocated to the file? How many clusters are overwritten? What is the name of the overwriting file? P.S. Don't pick the 2mb file, pick something around 20k. P.P.S. Confirm that the disk isn't an SSD, and isn't a shadow copy etc.
  13. Recuva won't delete thumbnails

    That seems rather bizarre, that you should delete a live file because it has overwritten a deleted file. Don't you recognise the thumbnails? Is thsi FAT32? What is the name of the file that's overwriting these files?
  14. Recuva won't delete thumbnails

    Yes, a live file is one that hasn't been deleted. The thumbnails belong to the live file that has overwritten the deleted clusters. They do not belong to the deleted file (if the deleted file has been completely overwritten, that is). If you look at the comment alongside the file you will see what is overwriting the deleted file, and in Advanced mode you can see whether some or all clusters have been overwritten. You cannot get rid of anything that belongs to the overwriting file. It is live data.
  15. In my opinion there's no practicable chance of recovering overwritten data no matter what the overwrite pattern was, so yes, multiple passes is pointless. And there's even less chance of recovering what was there 48 hours, or six months ago.