Welcome, Guest. Please login or register.

Author Topic: Experiences with SFSsalv on an accidentally-formatted SFS volume  (Read 817 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline LoadWBTopic starter

  • Hero Member
  • *****
  • Join Date: Jul 2006
  • Posts: 2901
  • Country: 00
Experiences with SFSsalv on an accidentally-formatted SFS volume
« on: February 26, 2017, 12:48:14 AM »
My original question is below, but I'm going to turn this into a short description of my experience with SFSsalv on an SFS 1.279 volume which was accidentally SFSformat-ed.

Again, the data wasn't critical, but there were some things I would rather not lose if I could avoid it, but not a disaster if I did.  Remember, kids, keep backups!

Immediately after realizing I had run sfsformat against dh2: and not dh2.0: I fired up SFSsalv in deep scan mode.  It uncovered over 95,000 files in about 3.8GB.  I set the "recursion" option and selected "All" from the root of the drive, then proceeded to "Undelete" onto the new volume to which I was copying things in the first place.

However, what I found was only about 280MB of data was recovered.  Surely that couldn't be right.  So I ran it again and got another 150MB used space.  I assumed from here on out I was only gaining about 150MB of recovered data with each run and was dismayed to discover I was recovering the same 150MB over-and-over with the new copies being renamed by incrementing the last letter of the filename.

A new tactic was necessary.  At the root I selected "None" then entered one of the larger directories, selected "All" (with the recursion option still set,) then performed the undelete.  To my great happiness I found that all of the files SFSsalv said it would recover were recovered.

As this was becoming an exercise I started again from scratch with a freshly-SFSformat-ed destination.  This time I went into each and every directory to recover and selected "All", and upon completion of the undelete I found every single file was accounted for.

Well, at least the files SFSsalv said were recoverable.  There are some files still in the "---- BAD DIR ----" directories which have not been sorted.  Some files are corrupted of which corrupt icons are more easily detected, and some files are out-right missing.  This did kind-of surprise me as I expected all files would be recoverable as the format is essentially a QUICK format, but further reflection and I understand how the results are, in fact, possible (and, in fact, occurred!)

All-in-all I would say the exercise was proof that an SFS volume is mostly recoverable in these circumstances, and final proof of the axiom that a potential always exists, even in the best of circumstances, for some lost data.

The whole thing was oddly satisfying, and at the end of it I have a nice 120GB SSD installed and a far more quiet 4000D :)


   While transferring from one SFS volume to another, I accidentally formatted the wrong volume (whoops!)  Okay, yes, no backups and the data is not necessarily all that critical.  BUT I thought I'd try to salvage, anyway.

I ran SFSsalv in deep scan which found over 95,000 files, about 3.4GB of data.  But the first "Undelete" only recovered about 280MB, then about another 145MB, then 250MB, and so on.

WTF?!  Is this normal to have to run multiple passes on SFSsalv?  Is there something better to recover SFS volumes after a format?
« Last Edit: February 28, 2017, 11:25:57 PM by LoadWB »
 

Offline LoadWBTopic starter

  • Hero Member
  • *****
  • Join Date: Jul 2006
  • Posts: 2901
  • Country: 00
Re: SFSsalv taking multiple passes?
« Reply #1 on: February 27, 2017, 12:07:53 AM »
One thing I have figured out about SFSsalv is it works better if you enter each directory and perform the undelete from within, rather than from at the root.