arSFSDoctor v1

						Welcome to arSFSDoctor v1
						--------------------------------------
						

I started working on sfsrecovery tool since 2019 just after losing my hard disk.
Goal is to make it look and feel like original SFSDoctor and run on AROS to
recover lost/deleted/lost 
and corrupted sfs disk/partitions.

Look and Feel it's not same as SFSDoctor yet but i am happy with the current
design of arSFSDoctor.



What used and who helped during the build.
-----------------------------------------------------
-Some sourcecode from ASFS linux driver are used.
-Functions from sfscheck.c from aros tree.
-libdiskio/ by Fredrik Wikstrom <fredrik()a500.org>
-Btree build - by Krzysztof Smiechowicz <deadwood()wp.pl>
-some functions are taken from opensource testdisk.
-serk118 classes/mui/zune designe and rest of the implemention <Serk118
<serk118()gmail.com>

-I like to thank John Hendrikx for all the helps/sample codes and directions  -
John Hendrikx <hjohn()xs4all.nl>

-LunaPaint used for icon.
-Arzip to archiive.
-Txt2Pdf for pdf.
-gcc compiler.
-JanoEditor.

Buttons and functions
------------------------------

About - Displays about window.

Devices - available sfs drives.(scan & show devices button brings up none sfs
drives too).

Chack Disk - same way how sfscheck works on AROS (Need bit more work).

>Scan Disk  - scans for lost/damaged/croupted and deleted files/folders.
>Scan Options - recover and scan methods.
>Quick Scan - Basic valid unbroken structure/admin/container data scan.
>Standard Scan - slighly faster than Deep Scan and yet again effective results.
>Deep Scan - slow but very effective results.
>Listview - shows all the files.
>Select All/Undo Selected - sellect/unselect all files/folders.
>Mark/unmark - Marks and unmark selected files/folders

>Save Log -- saves log file to selected path.
>Clear Log -- clears the log.

>Clone Drive -- clones selected partition drive to image file.
>Clone Drive - generates a temporary TSFS mount file to same directory/device
where image file is,
>copy the mount file to devs/dosdrives/ and than you should be able to  mount
image file by using system/DiskImageGUI.
>Return to Main -- back to main screen.

>Quit -- exit to AROS dos..



Planned to add more
-------------------------------

--Langauge -- Catalogs(%1 done).
--Advance scan (scan from=xx till=xx , within available partition size
range)(%10 done).
--Image scan only..
--Repair partition (%60 done).
--Load/save log file(%20 done).
--Load/save partition metedata(%30 done).
--Sfs structure repair (%10 done).
--Sfs2 implemention(%0 done).
--Optimise read and write methods to gain more speed(direct i/o and cache
i/o)(%10 done).
--Clean readme guide in pdf (%5 done).



Example steps
-------------
1.Open arSFSDoctor.
2.Pick a sfs partition from the device list.
3.Scan Disk.
4.Select Deep Scan.
5.Click on Scan Now button
6.select all the files and mark them.
7.Click on Recover Now and select location where you like to save your salved
files etc..
8.Return to Main.


All started with johns help
-------------------------------------
I haven't looked at it for almost 20 years, but let's see.

First try and locate the Root block.  I think it should start with 
"ROOT" (but I didn't check).  SFS has two of these, one at the start
of the partition and one at the end.  One of the fields contains the
block size, which will be the size of all important SFS blocks.

The root block has the root object container, which contains information
about files and directories in the root directory.  The object 
containers basically hold one or more smaller structures that represent
files and directories.  Scanning them all should give you a list of 
files and directories.

The root block also has the root of the Extent B-Tree.  This is a 
standard B-Tree structure (not a binary tree) that is used commonly in 
all kinds of system, you can read about how they work on Wikipedia if 
needed.  The B-Tree holds the information about *where* all the data is 
located for your files.

To recover your files, I'd do this:

- Find one of the root blocks, if not present, then figure out the block 
size your disk was using, and scan every block in turn to see if it 
looks like an ObjectContainer (check the fsBlockHeader's ID, check if 
the ownblock number is equal to the block you are currently scanning, 
and check its checksum).  So if you currently have block 12, and you see 
a block with the correct id, and ownblock = 12 and its checksum is good, 
then that's probably a valid ObjectContainer.

- With all the ObjectContainers found, you can extract filenames and 
directory names from these, but also the number of their first data 
block (in the field data) and the file size.  For small files (less than 
blocksize) this data block will be enough to recover the data.
For larger files, you might be lucky and all the remaining blocks are
found after the first one (if the file was defragmented).  You can't be
sure of that though so...

- For larger files, you need to find all the BNodeContainers.  You could
scan these in the same way you found all the ObjectContainers (look for 
blocks with the correct id, ownblock number and checksum).

- With all the BNodeContainers found, you can try looking up the first
data block of a file in the B-Tree structure.  This is a bit complicated 
-- the B-Tree consists of non-leaf nodes (blocks that only contain 
pointers to other B-Tree blocks), the isLeaf flag indicates this.  Or it 
can be a B-Tree leaf block.  The leaf blocks contain extra
information per entry (see https://hjohn.home.xs4all.nl/SFS/extents.htm)

struct fsExtentBNode {
     ULONG key;
     ULONG next;
     ULONG prev;
     UWORD blocks;
};

The key should be a block of a file (the first of a range), that is 1 to 
65535 block long (depending the "blocks" field).  If the file is split 
up into more parts, then "next" will contain block number of the
next range of blocks.  You need to look this up again in the B-Tree 
structure to find out how large it is.

The B-Tree is a bit complicated, so let me know how far you get, and I 
can explain in more detail if you have questions.

You can for the most part ignore the other structures (bitmap, admin 
containers).  The fsObjects and B-tree containers is what you'll need to 
recover the data.

--John




contact me
----------
serk118()gmail.com (for bug report etc..)


WARNING
--------
Use at your own risk..