Jump to content
CCleaner Community Forums

Augeas

Moderators
  • Content Count

    4,376
  • Joined

Everything posted by Augeas

  1. Huge 4k or huge 52.4 gb? NTFS zaps cluster addresses on deleted files larger than 4 gb, so it would be very difficult to recover such a file, and is probably why only two clusters are listed.
  2. With TRIM enabled on the O/S and SSD the chance of recovering any deleted file from an SSD is just about zero. Recuva will scan the MFT to reetrieve the file names and cluster addresses, which still exist. The clusters will however be filled with zeroes. In Advanced Mode if you look at the file headers this should confirm the zeroes. Recuva will recover these zero clusters quite happily, but they are of no use. A professional data recovery service might be able to recover some of the files, at a cost, by reading the nand chips natively.
  3. Please don't post duplicate items. and try to pick a thread that's withn living memory.
  4. In Advanced Mode open Options/Actions and check Restore Folder Structure near to the bottom. This will give you the best chance of recovering your folders.
  5. Augeas

    thumbnails

    Right click on the list of files, Select View/Thumbnails
  6. Just clear everything from the File/Path box.
  7. If it's FAT32, and who knows, then there are particular difficulties in file recovery. Try a deep scan.
  8. Canon has a variety of operating systems, but I'm no expert, or even a tyro. FAT32, if that's what is used, is particularly evil when attempting to recover deleted files. Try a deep scan.
  9. The list of files you see in advanced mode is exactly the same list shown in the Wizard. I guess you had something in the filename/path box that excluded all your files.
  10. I think that SSD rationale has changed over the past few years. We've seen that Win 8/10 runs what Microsoft describes as a 'Traditional' defrag on SSDs under certain conditions, and we also know that excessive fragmentation causes excessive I/Os as NTFS ploughs through the MFT. So an occasional defrag won't hurt. Does any manufacturer forbid defrags? As for longevity, TLC SSD has an erase/write limit of a little over 300. Before anyone panics if I write 1 gb a day on my minute 120 gb device (and that is far more than I do) then the SSD should start slowing down in 110 years.
  11. Or to try to answer Don's original post, dump Defraggler. If you're on Win 8 or 10 (and have sys restore enabled, and have more than 10% fragmentation) then you'll get the Windows defrag described above. Mercifully Win 10 has sys restore off by default so those defaulters (me included) won't get the defrag. Why were you running a defrag against your SSD in the first place? What was the fragmented percentage?
  12. As TRIM came out with Win 7 in 2009, and SSDs before that, your audience might be limited. Zero filling a non-TRIM SSD might improve write performance but not for the reasons above (and also falsely claimed in the OCZ forums some years ago). An empty SSD block contains ones not zeroes, and no software on earth can erase NAND flash blocks. What zero filling does is to allocate a dummy page of zeroes to the LBAs instead of a physical page. The freed pages are subject to garbage collection, which erases them. Thus a pool of erased blocks is available for wrtes, and performance increases.
  13. Sort of, but with live files, and NTFS knows exactly where they are. NTFS doesn't care a bit about deleted files, and I can see no way of performing a recovery to the source disk: the mechanics of it are horrendous. (Well, I occasionally run a single file recovery to the source disk, but that's another matter.) It won't happen without a new file system, and I can't see anyone spending millions to enable this.
  14. I think you'll find that we have no idea whatsoever.
  15. That isn't how Recuva, or recovery software in general, works. Recuva will copy files it is recovering to a separate drive, so you will need an additional 3tb+ drive to hold the recovered files. In Advanced Mode go to Options/Actions and at the bottom of the pane check Restore Folder Structure. Then run your recovery. Although Recuva can handle the massive disks that some use today it's very difficult for a human to handle the millions of files involved. Beyond backup, beyond recovery.
  16. Please do not insult other members Nicon, it isn't constructive.
  17. 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
  18. 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 s
  19. No, but this wouldn't help you in renaming deleted files, would it?
  20. 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.
  21. Not a bad idea, but Recuva is not exactly Piriform's flagship product, so don't hold your breath.
  22. 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,
  23. 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.
  24. 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.
  25. 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 co
×
×
  • Create New...