These are the usage instructions for the 04/2019 version 0.98 of rd113
It will read and extract files from an uncompressed Iomega *.113 backup file.
See http://www.willsworks.net/file-format/iomega-1-step-backup
for a full description of the project and what I have discovered so far
regarding the file formats used.
See also the vtbl program which will decompress a *.113 image file.

These backups were typically written to Iomega removable media were released
with the drive installation software that came with the device.  To date I
have only worked with backups from Iomega 100Mb zip drives.  I believe the same
software can be used with 1Gb Iomega Jazz drives and 20Gb Iomega Peerless drives.
Apparently there were Mac and Linux versions, but I have only work with Windows backups.
The original software only wrote a backup file on the Iomega drive, but it could
then be copied to any medium.  A typical backup often required several zip disks.
In this case each disk was given a sequential sequence # starting with 1, and
a flag in the image file header was set indicating the file was part of a seqential 
backup spanning multiple disks along with the sequence number in the set.

This is version, 0.98, is the 2nd major release of the software.  It adds some options
which started as debug options but are useful enough that I now use them as the
primary means of accessing image files.  The new options allow better access to
image files that contain multiple incremental backups.
The current Win32 version is limited to 2Gb files per the early Windows OS standard.
This is not a limitation in the file format, it has to do with 32 bit compilers
and my code.  If built on a linux 64 bit system this limit goes away, but for your
average backup image from a zip disk collection it is not likely to be a problem.

The usage message below is seen if the program is run with no command line arguments:

rd113 version 0.98 compiled for WIN32

usage: rd113 <input file> [-c[#[:#]]] [-d] [-f] [-p<path>] [-v[v]] [-t] [-x]
attempts to summarize or extract backup file contents

optional -c[cat_off[:data_off]] display catalog from uncompressed file
      use cat_off if multiple catalogs and/or ':data_off' to map to data region
optional -f temporarily force compression & seq  flag to 0
optional -p set xtract <path>, so only extract files at or below <path>
optional -t save dir_list and run tests
optional -v set verbose mode to display more fields
optional -vv set very verbose display independently from -v
optional -x[#] set xtract flag, => all files unless set -p or max extract #
DEBUG options enabled
 -dd<hex offset>  - attempt raw data listing or extraction starting at offset
 -di  - scan raw dir_head and cat_head entries and summarize image data


The output above is from the Win32 version of the program.  If compiled for Linux
the only difference is that 'Linux' would be displayed rather than 'Win32'.

An <input file> name is required.  If this is the only argument given the 
program displays the information from both file headers, and the vtbl header.
Then exits.  Note this program only works with uncompressed data files.  If the
compression flag in the vtbl header is not 0, the program will not read further.
This can be over-ridden by using the -f option, but do so at your own risk, you
are likely to get garbage.  Using the -f option clears the compression byte and
the flag the controls testing the sequence # which is also stored in the vtbl.

As far as I know all image files start with a data region and end with a catalog
region.  However if the image has a disk sequence # > 1 it is not the 1st image file
in the backup and may well start the data region in the middle of a file.
The image files are arranged in blocks of 0x7400 bytes.  The first 3 blocks are used
for the header information so the 1st data block is always at offset 0x15c00.
Regardless of the image sequence # a new data region or a new catalog region always
occurs at a block boundry, ie file offset = block # * 7400.  The space between the
end of a region and the start of the next is padded with zeros.

Lets talk about the simple case first, there is only one backup in the image and it
is entirely contained in the image file, ie only one zip disk was required.
The data region starts at offset 0x15c00 with a directory entry which starts
with the 4 byte long hex value 0x33CC33CC which identifies the structure.
Each directory entry contains some fixed data regions defining the file length
and its attributes and several variable length unicode strings (which maybe empty)
and that define the file name and where on the original disk it should be restored.
This is followed by the raw file data, and couple validating signature bytes.

This sequence is repeated until the end of the data region.  This region is listed
with the -dd# option where the hex number is the offset to the start of the data
region of interest.  Typically 0x15c00 for the first file on the 1st disk image.

A catalog region follows the data region at the next block boundry.  In the simple case
there is only one catalog and it can be accessed with the -c option (mutually exclusive
from -dd or -di).  The catalog provides an in order list of the directory entries but
is quicker and a little easier to parse as it contains no file data to be skipped over.

But its often messier than the simple case above.
1st it could be just one backup, but a backup that spans multiple disks.
The basic structure is the same, but the data region may continue onto the next
disk (or disks).  In this case each of the disks contains a partial catalog  at
the end of the image which should be the catalog for the current disk (although I 
have seen one case where an intermediate catalog did not match its disk contents).  
The some data for the last file in the a data section may also be continued on the 
next disk (more about this later).

Or there could be multiple incremental backups all on the same disk.  In this case
the 1st data region will end, and be followed by its catalog starting at the next
block boundry.  Following this catalog a new data region starts at the next block
boundry.  The two samples I have seen of incremental backups contain multiple pairs
of data and catalog regions.  On a disk like this the -di option summarizes the image 
contents.  It lists the starting offset of each new data or catalog region.  Each data
region is terminated by a directory entry with the PF_END flag set.  When listing 
via -di a summary of the backup contents is listed {backup #, # dir entries, # subdir, 
#files} whenever the PF_END flag is seen, and the backup # is incremented for the disk.
The PF_END flag signals the end of a backup in the image and is followed by a catalog.

So on a large backup that spans multiple disks the -di listing may never see
a PF_END flag for the last data region.  I need more sample data, if you have some to 
volunteer let me know.  It appears in a multi disk backup an contianing incremental 
backups that the image may end in the middle of a data section without a catalog at 
the end.  Conversely a single backup that spans multiple disks appears to always contain 
a partial catalog at the end of the image although the last files data may be split 
between two images.  With the two sample incremental backup images I've seen the 
catalog has not be split between two disks, but file data has been.  I do not know
if this is a general rule or not.

You can view a single incremental backups data by using the -dd# option to parse
the file data region or the -c# option to parse an individual catalog in an image.
If a single hex number immediately follows -c it is taken as the offset to
the catalog of interest in the file.  If -c is used by itself the program uses the 
information in the file header assuming its not an incremental backup.  But this often 
fails with no listing with an incremental backup as the file may not end with a catalog.
The -dd# is the most reliable, it reads the actually data in the current file.
The -c# reads the catalog data in the current file, and in a multi volume backup
this may point to files on a prior (or possibly the next image?)  I added some logic to
detect if file offsets exceed EOF for this disk, but doubt this happens.  I see no way 
to detect if a file listed in the catalog is on a prior disk.  So I recommend using -dd#
for the first and last data section of an incremental backup disk.

There is a 2nd possible option to -c which is preceeded by ':'.  It defines the 
hex offset to the data region the catalog is referencing.  When provided the catalog
displays additional information about the offsets to the start of the data region for
this file, ie the start of the file header, and the offset to the start of the file data.
This was a proof of concept that one could extract files using the catalog data which
has not been impliemented, but is of interest.  One can also use '-c:#' to use the 
default catalog offset with a data region offset of #.  Safer approach is to specify
both.

-dd#  normally is used to start the display or extraction the file data at hex 
offset # in the current file.  Use the value decimal -1, ie -dd-1, to find the first
file id in this backup and display all subsequent files in the backup following this.
However if the current image contains incremental backups the listing will terminate
at the end of the 1st incremental backup in this file.  To display others there starting
offset must be obtained with the -di option and then used with -dd# to get the listing.

Currently the -x option only works in conjunction with -dd#
It could be implemented for -c, but doesn't seem worth the effort and
one has more control over the starting position using -dd#.



The issue of multiple disk complicates things.  If possible and you have all the
disk images and enough disk space I recommend concatinating the images together.
vtbl will do this for compressed images.  The following allows one to handle the 
case where a files data is split between two image files.  If the -x option has
been used and is active the data for the current file on image will be output.
Then an interactive prompt will appear asking for the next disk image file name in
the sequence.  If a valid filename is given, the data from its 1st data segments
will be appended.  There is no error checking on this, its not a common occurrance.
But is one method of extracting files that span two disk images.

If you are not sure what your disk contains I recommend using 'rd113 <file name>'
with no options to see the vtbl checking compression and seqence information.  Then 
'rd113 <file name> -di' to summarize the image contents if its an uncompressed image.
If there are multiple data segments in the image file the offsets from -di output
can be used to view individual regions starting at that offset with -dd#.

Hopefully this makes some sense so far.
Operationally file extractin is always enabled with the -x option and must be
used in conjunction with -dd# to indicate where the extraction parsing should
begin.  There are two ways to control the files extracted.
The -x option takes an optional '#' argument where the # is a decimal value
representing the total number of files to be extracted.  Useful especially if you 
want to extract a limited number of files rather than a sub-tree.  The -x# and -p<path>
options can also be used in together to limit the files extracted from a subtree.

Alternatively there is a -p option that allows the definition of a sub-tree path.
Only files that are in or below that subtree will be extracted.  This can be a little
tricky, depending on where one starts via -dd#, as the paths are dependant on whether
or not the code sees a drive spec when started at this position in the file.  Its best to
1st do a listing via -dd# and then use the path displayed with the -p<path> argument
to control extraction.

Last but not least during file extraction the output path is relative to the current
directory from which rd113 is being executed.  I suspect you do not want to over write your
current system file.  So the safe thing to do is create a new directory and work there.
Under Windows the backup files retained disk drive specs such as 'C:' for the start of
each path at the start of each backup.  If the -dd# listing includes a drive spec
in this format it will be written to a subdir 'C_\' in the current directory.
If the -dd# listing does not include a drive spec, then do not include one in the
-p string but it does use the ':' not the output spec '_\'.  Also be careful as I have 
seen both upper and lower case drive letters used. 

Warning I have only worked with backups created on Windows systems which contain the
drive letter specification.  I assume there are no drive letters in a Mac or Linux
backup, and hope this will be transparent, but if anyone has trouble with this and
is willing to share an example please send me an email.

The -v and -vv options enable more verbose modes and should probably be avoided unless
you are having a problem.  They are there mostly for my debugging.

------------------------------------------------------------
A few examples:

below is a simple case, single disk image which is a single backup file:

rd113 ImageB.113


rd113 version 0.95 compiled for WIN32

 using:file ImageB.113
Label: OneStep - 1/5/2017 - 8:15 AM
VTBL volume contains 215 logical segments
created: Fri Dec 27 03:00:30 2019

flag 0x20:
version: 71:0
dir size 0x18f2 data size 0x612093
QFA physical start block 0x3 end block 0xda
compression byte 0x0
OS type: d => Windows 95

total block count 219 - 1 dir blocks => catalog at offset 0x62c800
offset to end of file = 0x63b000 => 220 blocks
Job 2, Disk 1

-----------------
same image as above, but just the 'Image data' portion of -di


Image data:
Backup 1 data starts at offset 0x15c00
PF_NEW flag seen in 1st record, probably the start of a new Backup
Saw PF_END flag in this enty, a catalog should follow at 0x62c800
Backup 1 saw 35 dir_head entries containing 4 subdir 31 files
catalog starting at offset 0x62c800 contains 35 records
debug routine called and terminated execution

-----------------
below are sample outouts from a 3 disk set which forms one complete backup.
Again I only include the Image data portion of output from -di for comparision:

 using:file Image1.out
...
Image data:
Warning this image is seq 1 in a multi disk backup set
Backup 1 data starts at offset 0x15c00
PF_NEW flag seen in 1st record, probably the start of a new Backup
some file data for this entry is continued on next disk image
Backup 1 saw 787 dir_head entries containing 44 subdir 743 files

catalog starting at offset 0x6bdf400 contains 468 records
----
 using:file Image2.out
...

Image data:
Warning this image is seq 2 in a multi disk backup set
Warning image data at 0x15c00 does not start with a DIR_SIG, skip ahead to 0x5f7170
Backup 1 data starts at offset 0x5f7170
some file data for this entry is continued on next disk image
Backup 1 saw 23 dir_head entries containing 9 subdir 14 files
catalog starting at offset 0x72fb000 contains 468 records
----
 using:file Image3.out
...

Image data:
Warning this image is seq 3 in a multi disk backup set
Warning image data at 0x15c00 does not start with a DIR_SIG, skip ahead to 0x5cf122
Backup 1 data starts at offset 0x5cf122
Saw PF_END flag in this enty, a catalog should follow at 0x6c12000
Backup 1 saw 521 dir_head entries containing 38 subdir 483 files
catalog starting at offset 0x6c12000 contains 1331 records

---
Note that only the last image contains a PF_END flag indicating the end of
data for this backup.  The last catalog above is the catalog for the entire backup.
---------------------------------

Finally the output from one of the few incremental backup images I was loaned.

Again just the Image data portion from -di:


 using:file Lane02.out
...
total block count 12698 - 6043 dir blocks => catalog at offset 0xbc78c00
offset to end of file = 0xc60d954 => 6993 blocks
eof for this image at 0xc60d954

Image data:
Warning this image is seq 2 in a multi disk backup set
Warning image data at 0x15c00 does not start with a DIR_SIG, skip ahead to 0x528ce7
Backup 1 data starts at offset 0x528ce7
Saw PF_END flag in enty 48, a catalog should follow at 0x1aa6400
Backup 1 saw 48 dir_head entries containing 10 subdir 38 files
catalog starting at offset 0x1aa6400 contains 133 records

Backup 2 data starts at offset 0x1ab4c00
PF_NEW flag seen in 1st record, probably the start of a new Backup
Saw PF_END flag in entry 17, a catalog should follow at 0x1e9d400
Backup 2 saw 17 dir_head entries containing 8 subdir 9 files
catalog starting at offset 0x1e9d400 contains 17 records

Backup 3 data starts at offset 0x1ea4800
PF_NEW flag seen in 1st record, probably the start of a new Backup
Saw PF_END flag in entry 190, a catalog should follow at 0x46a1800
Backup 3 saw 190 dir_head entries containing 23 subdir 167 files
catalog starting at offset 0x46a1800 contains 190 records

Backup 4 data starts at offset 0x46b0000
PF_NEW flag seen in 1st record, probably the start of a new Backup
Saw PF_END flag in entry 93, a catalog should follow at 0x65a4400
Backup 4 saw 93 dir_head entries containing 21 subdir 72 files
catalog starting at offset 0x65a4400 contains 93 records

Backup 5 data starts at offset 0x65ab800
PF_NEW flag seen in 1st record, probably the start of a new Backup
Saw PF_END flag in entry 132, a catalog should follow at 0x8530c00
Backup 5 saw 132 dir_head entries containing 28 subdir 104 files
catalog starting at offset 0x8530c00 contains 132 records

Backup 6 data starts at offset 0x853f400
PF_NEW flag seen in 1st record, probably the start of a new Backup
Saw PF_END flag in entry 95, a catalog should follow at 0xa4d3000
Backup 6 saw 95 dir_head entries containing 19 subdir 76 files
catalog starting at offset 0xa4d3000 contains 95 records

Backup 7 data starts at offset 0xa4da400
PF_NEW flag seen in 1st record, probably the start of a new Backup
Saw PF_END flag in entry 14, a catalog should follow at 0xa5c2400
Backup 7 saw 14 dir_head entries containing 1 subdir 13 files
catalog starting at offset 0xa5c2400 contains 14 records

Backup 8 data starts at offset 0xa5c9800
PF_NEW flag seen in 1st record, probably the start of a new Backup
Saw PF_END flag in entry 631, a catalog should follow at 0xbc4d400
Backup 8 saw 631 dir_head entries containing 10 subdir 621 files
catalog starting at offset 0xbc4d400 contains 631 records

Backup 9 data starts at offset 0xbc78c00
PF_NEW flag seen in 1st record, probably the start of a new Backup
Reached EOF, some file data for entry 27 is continued on next disk image
Backup 9 saw 27 dir_head entries containing 6 subdir 21 files
ret = 0  during Backup 9
debug routine called and terminated execution
-----
per above this is the 2nd disk in sequence, and not the last.
The 1st backup does not start at 0x15c00, and the last backup has data that continues
onto the next disk image.  There are 8 full backups in this image and 1 partial.
The catalog for the last backup is not on this disk as the data continues on the next.
There are more files in the catalog for the first backup than were found in the
data listing as some are located on the previous disk.