Jump to content
Piriform Community Forums


  • Content count

  • Joined

  • Last visited

Everything posted by Augeas

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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?
  8. 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.
  9. 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.
  10. Recuva won't delete thumbnails

    It means what it says, that the clusters of the deleted file have been overwritten by a live file. What you are seeing are thumbnails (or whatever) from the live files. You can't overwrite these clusters, they contain live data. I suspect that this is FAT32? If it's NTFS you could run Drive Wiper. This will wipe the MFT and you will no longer get these messages. By the way these messages are returned from the normal scan that a deep scan runs automatically as part of its process. Files found by the deep scan component (with a [001234].ext file name) will not, and can not, be overwritten by a live file.
  11. After more than six years I don't think that he cares any more. Why do spammers tack on to such old threads? For spam this surely is, or will be.
  12. Data recovery

    What results are you getting? What options are you using?
  13. I would seriously consider using a professional data recovery company. The disk is huge, and using a piece of generalised software on a home machine is going to take days, if not weeks, interspersed with suggestions to run this option or that. Bite the bullet, and backup any results you get.
  14. Filename syntax incorrect

    Not really. The file name will be in a folder somewhere (FAT or NTFS) and it looks as if it's been overwritten or corrupted somehow. The folder path can't be constructed (see the ? in the path) so what's happened to the folder I've no idea. As the file is in one extent you could use a freebie hex editor like HxDen and copy all of the clusters in one go, but that is quite a task. If it's FAT you could use HxDen to rename the file in the directory to something readable and then retry Recuva, if you could find the directory that is. You won't be able to do this with NTFS as the MFT is protected. Or you could - and this is what I would do first as it's easy and non invasive - run a deep scan. I don't think that files that are in folders are recognised by a deep scan but it's worth a try. A deep scan doesn't recognise file names.
  15. Mta, on a HDD you can use whatever character you wish, it will make no difference. As user data is scrambled and coded by the disk controller before being written to the disk there is no way to determine what sequence of ones and zeroes was used on writing nor what it will be on overwriting. So you can overwrite an unknown sequence with another unknown sequence, but you can never actually overwrite a one with a zero, or vice versa, as the scrambling removes the knowledge of whether a one or a zero has been, and is being, written. Overwriting a one with a zero is a logical construct far abstracted from the storage device. On an SSD you can't overwrite anything, you can only write new pages, so the proposition that you can overwrite with zeroes or ones or whatever, no matter how many times, is merely fanciful. To the SSD controller a page is either valid (i.e mapped to a lba and visible to the O/S) or invalid (i.e. not mapped to a lba and not visible to the O/S). This does not represent what the O/S considers to be live or deleted files. File life or death (and fragmentation as well, but that's another long bedtime story) to the O/S is specified in the MFT, or FAT tables. The SSD knows nothing of these. Deleted (TRIMed) SSD pages will be inaccessible to any operating system. Garbage Collection will empty invalid pages by setting all cells to 'ones', and those pages will remain inaccessible until the SSD controller receives a write request and decides to use them. DDR4 ram is volatile, but there are some hybrid cards with ram and non-volatile flash in the pipeline, perhaps this is what is meant. This is a long way from the O/P's suggestion.
  16. Video files recovered unplayable

    I believe that the file system for SD and SDHC cards is FAT32 and the video file format is AVCHD, and the recording is split into discrete elements and stitched together using Canon's software. SDXC cards use ExFat. Canon gives a warning message before formatting that all data will be lost. That's the extent of my Canon knowledge.
  17. These are NTFS system meta files. I wouldn't touch them. Dump the existing files, repartition, reload the files.
  18. Stuck on Analysing Damage

    You can cancel Stage 2 (or 3) and still see, and recover from, the list of files found.
  19. There's no option to put files back into their (original) folders. You can ask Recuva to restore the folder structure within the folder you're recovering the files to (excuse excruciating grammar). Files with a ? in some part of the path wont have their full folder structure restored as some or all of the folder structure has been destroyed.
  20. Recuva Stuck

    Why not, if you have the time. Cancel as soon as it enters stage 2.
  21. Recuva Stuck

    Just cancel it. I have never noticed any difference if I cancel stage 2 or 3. You will still get the list of results and can recover any of those files you wish. (I mean cancel within the stage 3 box, not cancel the entire job!)
  22. If you mean their original folders then no. However you can recover to a folder on a separate device and build the folder structure within that folder, and then copy as required back to the original folders. The option to do this is in Advanced mode, Options/Actions, a check box near to the bottom.
  23. As I said, it's unlikely. But as we don't know whether the device was formatted, we don't know exactly what you've done, and we don't know what Eraser does, then we can't say for certain.
  24. The $nnn files are system files set up by NTFS when a device is formatted. It's unlikely that these files will contain any useful data. I don't think that removable devices have shadow copies. It's up to you if you want to reuse or destroy the flash drive. Any Eraser questions should be directed at an Eraser forum.
  25. rootkits

    This is almost unreadable, can't you try a little puctuation? Does this have anything to do with CCleaner? Your third post is quite spammy too.