Jump to content
Piriform Community Forums

Augeas

Moderators
  • Content count

    4,082
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Augeas

  • Rank
    Moderator

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

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

Recent Profile Visitors

2,251 profile views
  1. Cc scamed me

    Please do not insult other members Nicon, it isn't constructive.
  2. How to Handle SSD Drives

    If you have 50,000 files on your SSD then 500 fragments is just a rounding error. If you have one file with 500 fragments, that's another matter. If you're on Win 8 or 10 and if you have Sys Restore enabled, and fragmentation is greater than 10% (whatever that means) then Windows Defragger will defrag your SSD once a month. Before anyone says this is an Optimise, it is in Microsoft's words 'a 'Traditional Defrag'. This is apparently to manage the fragmants in volsnap files. Does Defraggler replace Defragger? (I'm not a Defraggler user.) Unless you have many fragments in one file (say 100+) and you use that file frequently, then forget it.
  3. I didn't know what benefit other than very slight it would make towards renaming the $R files. I don't know the circumstances under what the two software apps run, let alone what they do internally. Folders exist as a record in the MFT and the owning folder for a file is found by linking back from an offset held the file's MFT record. As this psyically exists or it doesn't I can't see why one piece of software can find it and another can't. The recycler folder is extremely unlikely to have been deleted so it still should exist in the MFT, and the link back value in the file's MFT record should be valid, so Recuva should find it. I know I have previously run Recuva and seen the recycler folder, so I know Recuva can find it. I run Recuva in Advanced Mode with the top three boxes checked in Options/Actions, if that's any help.
  4. No, but this wouldn't help you in renaming deleted files, would it?
  5. As far as I know there's no way of wiping the MFT without also wiping free space. Do you mean the Wipe MFT component of Drive Wiper, or what? If so then the notice that Wipe MFT has completed may not necessarily coincide with the actual event. Wipe MFT fills the MFT by allocating enough small files to fill it (and overwrite what was there before) and then deleting them. This is a NTFS heavy process. I can't see that the cluster size would have much, if any, affect, except by reducing he number of I/Os required.
  6. Not a bad idea, but Recuva is not exactly Piriform's flagship product, so don't hold your breath.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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?
  12. 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.
  13. 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.
  14. Meta Cleaner!

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