Jump to content
Piriform Community Forums

Augeas

Moderators
  • Content count

    4,104
  • Joined

  • Last visited

Everything posted by Augeas

  1. Not a bad idea, but Recuva is not exactly Piriform's flagship product, so don't hold your breath.
  2. In a normal scan Rcuva doesn't look at the disk but gets data from the Master File Table. All files are listed in the MFT, and although the records flagged as deleted in the MFT are reusable it is common for there to be more files listed in the MFT than are on the disk. Foe example fill a disk with 1,000 files of 100 mb each, delete them, then fill it with 500 files of 200 mb each. The disk will be full but the MFT, and Recuva, will show 500 deleted files addressing 500 x 100 mb of data. I would expect the deleted files to have a state of overwritten, as there is no real free space available, but I don't know the exact circumstances that shows free space in your case.
  3. If a scan takes 11 hours then it's a deep scan. No date iformation of any sort is stored in deep scan found files. A normal scan has a date last modified (and has had for years) which is as near to what you want as you will get. Depending on how files were deleted, this is the deleted date.
  4. That certainly is an old thread. Well, it makes me feel old. Files sent to the recycler (which is just a system folder) are renamed with a $i and $R suffix. The $R file is the complete file and the $I file, which is 544 bytes if I remember correctly) holds the file name and folder. You can recover and read the $I file with Notepad. You can recover the $R file as well, I don't know if it is the original file untouched, try renaming and opening it. You could also try the copy back to the recycler as the old thread describes, at your own risk.
  5. Recovering a 'simple text file' is no easier, or more difficult, than recovering the most securely triple-encrypted file. A text file is merely one where the bit sequence can be translated into a pattern recognisable by a human being. It means nothing special to Recuva, or the disk, or the operating system. To them it's just a string of bits. As stated above, Recuva will copy faithfully whatever is in the deleted file's clusters. What's recovered is what is on the disk. So Recuva did what it should have done. That the end result is not what was expected is unfortunate, but Recuva can't conjure up what isn't there. I's still puzzled by the file being empty yet being in json format. Either it is empty, or it contains some Javascript coding. Now you say that you reinstalled Chrome. I'm not even sure if you're looking at the new bookmarks file, presumably empty or nearly so, or what.
  6. Recovery software does not guarantee that any file can be recovered in its entirety. Recovery is a copying operation, and Recuva will copy exactly what is in the deleted file's clusters to another location. Recuva in advanced mode will show the cluster number, so if you use a hex editor you can go to the start sector on the disk and see that what you have recovered is exactly the same as the deleted file: or you can take my word for it. A state of excellent means that no clusters from a live file are overwriting your deleted clusters at the time Recuva was run. We've no idea how the file was deleted nor what has happened on your pc since, nor what the file system is, so it's not possible to say why you are not seeing what you want to see. I don't even know what should be seen in a Chrome bookmarks file. A brief few minutes on Google shows that json files have no file signature, so how did you know you were looking at a json file if there were no contents?
  7. That info is being plucked from the internet somewhere. If you really only have the first fragment of the file, as described above, then there's no practical way to retrieve and join the other fragments without professional help. Other recovery software might make a wild guess, but that's all it is. If it's a commercial album then what you want is available elsewhere, easily and cheaply.
  8. A deep scan runs a mormal scan first, so any files and folders listed are from the normal scan. A deep scan does not access the MFT so file names and folders can't be extracted. A file found by the deep scan will have a file name of [001234].ext, no path info and will always be in an excellent state. However a deep scan can, and will, only retrieve the first extent of a fragmented file, as there is no information available to link file fragments together. The other fragments may still exist but there is no way to link them without significant skill or professional help. This may be your problem.
  9. Meta Cleaner!

    Yes, Options/Settings/Secure Erase/Simple Overwrite
  10. I have never experienced this but I can say that there's no physical log created by Recuva, so unfortunately, no.
  11. Meta Cleaner!

    What? This isn't really a suggestion, is it? A CC normal deletion just runs the equivalent of a shift/del, so the file is flagged as deleted in the MFT and the data remains until overwritten. A secure erase will overwrite the data before deletion, one pass is quite sufficient.
  12. Unable to open recovered documents

    There's no guarantee that anything can be recovered. We do not know what operating system nor what search criteria you're using, so it's difficult to advise.
  13. Unable to open recovered documents

    Files beginning with $ are usually live system files, and can be neither deleted nor recovered. Unfortunately there is no magic way to recover corrupted deleted files. If the data's gone then it's, well, gone.
  14. No. Recuva can search for and display undeleted files, but it won't delete them, for fairly obvious safety reasons. Can't you open Explorer and delete something? If Explorer is a no-goer then you might be able to use CCleaner to release some space. You can run the portable version from a flash drive without having to install it. If it runs then try a simple task to empty the recycler, run a normal clean, clean cookies, clear old restore points. This might give you some breathing space. Or expand the partition if you have the space available.
  15. Wiping free space

    I would advise against it, although there's nothing physically to stop you. The way WFS works is to fill the disk with zero-filled files, then delete them. If you use the pc when the disk filling is taking place the response will gradually slow down and stop as the pc struggles to cope. So no, really.
  16. The SSD has to be told what pages are no longer wanted (deleted) and the O/S has to do that, which is the definition of TRIM. XP doesn't have the capability of issuing TRIM commands as I understand it so the SSD has no way of knowing what's live and what isn't. File deletion takes place in the MFT, not at the storage device level. (What the Defraggler screen shot is showing, by the way, is entirely constructed from the MFT, or the MFT bitmap to be precise.)
  17. I don't think that XP supports TRIM natively, and defraggler runs under XP, so no, although there might be a utility available from the SSD manufacturers to do the same thing.
  18. LOCK SCREEN

    You should be finding at least 20 $ system files. Too late here to continue (and I'm out of ideas).
  19. LOCK SCREEN

    Did you check Check Scan for Non-Deleted files? If you have nothing in the Filter/Path box then it must find something.
  20. LOCK SCREEN

    No one knows whether it will stagger back into life or not, nor could we say whether a stop and start will have the same problem or not. It's up to you. However, if the disk has been formatted I would cancel the job, go into advanced mode, select Options/Actions, uncheck Deep Scan, Check Scan for Non-Deleted files, and run the scan again.
  21. LOCK SCREEN

    12tb? Are you a commercial enterprise? A normal scan should not take too long to analyse, as it is reading the MFT only. I don't know how many files there are on 12tb but even if there are a few million the scan should only take a few minutes (if it gets to stage 2 or 3 you can cancel the scan and still see the results without any apparent deleterious effect). If it's a deep scan then I guess it will take forever. Users with 2 or 2 tb disks complain that a deep scan takes days, so 12tb? If Recuva did finish, and found multiple millions of files, what human brain could sort that out? I doubt if I could.
  22. Who is dada123 claming to be a member

    No, he or she joined about 12 hours ago and (I assume) posted a spam post on your thread. He has been flagged as a spammer by one of the mods which removes his posts, so you will see nothing on your thread. No need to worry.
  23. why do you ban people for saying "bump"

    OK, let's step back a little and wrap this up. Yeah3346, you can post anything relevant to this forum as you wish, subject to the same rules as everyone, which I try to interpret (and don't always succeed) as don't post anything you wouldn't say face to face. Nobody holds any grudges and in a few days I for one will have forgotten your username or what you posted. I think that we all appreciate that the original banning for bumping was harsh, so in future the quite rare bumps will just be deleted. I'll close this thread now, enough has been said.
  24. Probably not a lot, but your conception of data recovery might be rather hazy. After all, 'Recovering permanently deleted files' is a little contradictory. No deleted file can be guaranteed to be recovered, and no operating system cares about, or helps in, recovering deleted files. A deep scan runs a normal scan first, and those with a file name will be from the normal scan, and those with a numerical name in square brackets will be from the deep scan. The deep scan looks for a particular set of file signatures in every non-allocated cluster. Those clusters with a match are listed, along with the following clusters, until another cluster with a file header, or a live file, is found. Only the first extent of a file is found, as there is no way of linking extents, so video or audio files - which are usually large and more likely to be in multiple extents - are quite often unplayable. The normal scan files are found by following the cluster addresses in the MFT. Recuva will recover whatever is in these clusters, whether they have all or partly been reused since file deletion. Any corrupt clusters are unlikely to display or play correctly. Very large files, over 4gb, will have the cluster addresses zeroed by NTFS so recovery is impossible. If the file system is FAT32 then the cluster addresses are half-zeroed by the O/S. Zero byte files are only found with a normal scan. Naturally they can't be recovered.
  25. Recovering non standard type files?

    Recuva will recover any file found in a normal scan. More precisely, it will copy the contents of the clusters pointed to by the deleted file's entry in the MFT, whatever the contents of those clusters are. In a deep scan only a subset of file types are found.
×