Recovering files with SFSSalv

 
Home    Tutorials    Recovering files with SFSSalv
 

SFSSalv is a program for recovering files from damaged SFS (SmartFileSystem) partitions. It can however not be used to repair any partitions, since it's a salvage tool only. When it comes to large harddisks (>4GB), it will only work with the NSD (NewStyleDevice) Patch, TD64 is NOT supported!  Furthermore, SFSSalv requires an Amiga with KS3.0 and 68020 CPU as minimum, and it can be downloaded from Aminet right here.

Since the Gui layout of SFSSalv is somewhat special, and any kind of documentation of the program is really non-existant, I have for some time thought about writing a small tutorial that explains the basic usage of it. Then after experiencing a corrupt SFS partition on one of the harddisks in my main Amiga 1200, I figured I could use this as an example of how to rescue files with SFSSalv.  It must be said however, that most of the information on this page is just a recreation of the events that originally took place. This is because my main priority right after the partition became corrupt, was to actually salvage the files present on it, and making a tutorial wasn't even on my mind back then. So when the majority of the sceengrabs below was made, I had already rescued the files.


The corrupt partition
In case you are interested, here's some info about the corrupt partition: A while back, I found a 2GB SanDisk Compact Flash card + CF to IDE40 adapter stored in a drawer, and even though I didn't really need the extra storage capacity, I decided to put it in my towerized A1200 anyway. The thought was that it seemed like such a waste to just leave it unused, and besides, I needed something to be connected to an idle cable coming from the ATX power supply (I like having power drawn from all possible cables for stabilizing the PSU). So I attached the card + adapter to the secondary connector of my IDEfix Express adapter, and then made a single SFS partition on it.

The original plan was to use this extra storage space for non-important temporary stuff, but unfortunately I started saving various files from projects I was currently working on to it. Then one day I was doing some work on my PIconTools project, and upon saving a file - the screen just froze!  I was able to move the mouse pointer, switch screens, and click on icons and stuff, but other than that, there was no response at all. So a reboot was the only option here.

Since the latest changes to the file in question probably wasn't successfully saved, I decided to take the below picture before rebooting. The reason for this was to make it easier & quicker to add the new changes to the file later (I really hate re-doing stuff).



After rebooting, I noticed that on Workbench, the name of the partition had now been changed to ZZT:Uninitialized. So I opened a Shell and tested the partition with SFSCheck, which led to the following result:


Clearly the partition was now damaged! So then I had to try rescuing at least the most important files by using SFSSalv, and this process is explained down below.



Rescuing the files with SFSSalv
The first thing to do after starting SFSSalv, is selecting a Drive to recover files from. In my case this was ZZT:. Next up is choosing the Scanmode, which can be either Fast or Deep. With the latter selected, SFSSalv will in addition to already existing files, also scan for deleted ones as well (takes longer time). Since I was not interested in any deleted files, I simply used Fast Scanmode, and clicked the Start button to begin scanning the drive.



After a while, the scanning was done, and the below window appeared. Here is a basic explanation of its usage: The list shows all files and directories that's found on the drive, and you can simply navigate through the dirs by double-clicking them. The tall "/" button to the left acts as the Parent button. Files to be salvaged are selected by double clicking, but unfortunately you cannot select any dirs by doing so, because this will just enter the clicked directory. It is also possible to select all items in the list with the All button, while the None button clears all selections.

If the Recursive option is enabled, it makes sure that also directories + its contents can be selected in the list (with the All button). By disabling the Tree option, the entire contents of the partition will be displayed in a single list (with everything listed one by one).  When all wanted items have been selected, just click the Undelete button to proceed. This will bring up a directory requester, which allows you to choose where to store the salvaged files. After this is done, the rescue process will then begin. Have in mind that the resulting files will use the same paths as shown in the list.


As you can see from the image above, some of the directories are marked as "BAD-DIR". But this isn't necessarily the result of any corruption of the partition. The thing is that SFSSalv seems to be very picky about certain "illegal" characters being used in directory and file names, this includes the following ones: ? # $ % | ~ * [ ] ' ( ).


As for my own rescue process, I decided to first and foremost concentrate on the PIconTools files that I desperately needed to salvage. So I entered the PIconTools directory, enabled the Recursive option, clicked the All button, and finally hit the Undelete button.  Fortunately, the recovery was successful!



With the most important files salvaged, I then took a closer look at the "----BAD-DIR---00000002" directory.  It seems like this really is the ".recycled" dir on the partition, and the reason why SFSSalv treats it like a "BAD-DIR", is most likely because of the "$" character used in some of the file names.  In case you are wondering, the ".recycled" dir is a hidden directory on SFS partitions, where deleted files are moved to. Also, when a file is to be overwritten, the original file is first moved to this location. Just as an example, I can take the PIconCopy$BBO file, which is the second last version of PIconCopy saved on this partition. The actual last version of this file, exists in its original drawer, with its original name.


In addition to the files already rescued, I also contemplated doing the same with the files in the ".recycled" dir as well. But in the end I decided to quite simply salvage all 666 files on the partition instead (image below). Because even though no errors occured during the first recovery, there was still a chance that those files was somewhat corrupt anyway. Another reason was in case it would later turn out that I needed even more files from this drive.  And fortunately, even this recovery attempt was successful!




Some final words
Managing to salvage the files from the corrupt drive was such a relief. This especially goes for the PIconTools files, since I had put down a lot of work on this project.  I did of course have a backup of it, but this was old, and it didn't include the latest changes + documentation. Anyway, the end result can be found on Aminet.

As for the Compact Flash card with the faulty partition, it seems like only the start of the partition was corrupt, since no errors occured upon recovering the files from it.  In hindsight, I seem to remember having problems with this particular CF card in the past, which may also explain why it wasn't used for anything in the first place.  I'm not exactly sure what the cause of these issues are, but my theory is that either the card is a fake SanDisk, or it has some old cruft on it, or maybe it simply is damaged.  If I'm ever going to try using this CF card with an Amiga again, I will certainly clear it with DiskPart first. But no matter what, I will never save any important data on it again!





    Followed a link? Please go to the Main Site                   © Roger E. Håseth  2016