Jump to content
Piriform Community Forums

Augeas

Moderators
  • Content count

    4,104
  • Joined

  • Last visited

Posts posted by Augeas


  1. I guess that this is NTFS, the drive is visible to Windows with a drive letter, and you ran a Recuva deep scan.

    A deep scan runs a normal scan first, so usually you will get a list of file names and associated folders before all those [001234].ext files. These file and folder names all come from a scan of the Master File Table, they are not held within the files. If youi are getting zero file names, then either the disk has been formatted or perhaps the MFT is corrupted. NTFS needs an MFT to do anything at all, so if the MFT is corrupt then the MFT mirror can be used, This only holds about 16 records so it will only identify system files, but it enables access by Windows.

    A deep scan will scan all unallocated clusters for a file header, which identifies the start of a file and the file type. Only a subset of all possible file types are scanned. No file or folder names can be deduced from a deep scan. As the clusers are unallocated they will all have a state of excellent, but don't let that fool you. Only the first extent of a file will be found and be a candidate for recovery. Subsequent extents cannot be identified and will be ignored, so a recovered file may not open anyway.

    I should rerun Recuva with deep scan unchecked, and (in Advanced mode, Options, Actions) check Search for Non-Deleted Files, and check Restore folder streucture. It should be fairly fast and is worth a try.


  2. I think I'm getting there. You ran a backup tio an already existing folder on the G drive (Y-Folder), and purge, which:

    'Deletes destination files and directories that no longer exist in the source',

    wiped out everything already in that folder. You then ran a recover of the contents of Y-Folder back to the D drive, but none of the files recovered open.

    But that doesn't get provide a solution. The headers aren't Recuva's, but the files', and no file with zeroes in the header will open (except text files) as the file structure is unidentifiable. It's highly likley that the rest of the file is zeroes also.

    I wouldn't have thought that Robocopy would overwrite deleted destination files with zeroes, but something has.


  3. Btw what does "zeros" in Header mean? = BUT Header: all "00"

    File names, directory names, cluster addresses etc are all held in the MFT. What's actually on the disk could be anything. I'm still not sure what you did or were trying to do. Perhaps someone with experience with Robocopy can chime in.

     


  4. 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.


  5. 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.


  6. 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?

     


  7. 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.

    Zero filling a TRIM SSD is a waste of time, effort and the life of the SSD.


  8. 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.


  9. 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.


  10. 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.


  11. 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.


  12. 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.

×