rd113 info

RD113 Info

Last Update: 03/26/18 see warning end of page

This file contains information about three programs I created to parse some of the files created by the initial version of Iomega's 1-Step Backup program. See the OverView Page for more information about the Iomega programs which created backup files. This page pertains to 'Image.113' files created by the dtiom98.exe ver 4.1 and 4.4. The file format used in these files is described in 113 Format and is significantly different from the later Iomega 1-Step Backup Ver 5.3 which created *.1-Step files as described in 1-Step Format. At the end there is a short discussion about format of the downloadable installers. I have provided a Zip archive of Windows NT console application executables which should run under Win9x or WinXP and I suspect later versions of Windows. These executables were created with the freely available Open Watcom compiler. The C source code distribution is also available 1Srest-src.tar.gz. I'd rather you built it yourself than trying to make more OS specific downloads available. Make files for the compilers and OS I have attempted are provided. The linux version has been tested fairly rigorously, but you have to build it yourself.

I installed the w32_iom221a_en.exe download on a machine running WinME and made a number of sample backups. Then explored the data that running this 1-Step backup program produced and reverse engineered the 113 format above. This was all done by inspection and guess work, some of it maybe wrong. I am giving fair warning that its speculation, and I can not be held liable for guessing wrong.

The backup program, dtiom98, has a couple command line options that are set from the Win9x Programs menu for Iomega when the program is spawned:
'Backup files' spawns 'dtiom98 /p'
'Select options' spawns 'dtiom98 /b'
The 1st option above backs up the files from a database the program maintains on the system hard disk. The 2nd option allows modification of this database. The designers apparently thought a user would normally periodically backup the same groups of files, normally leaving the data base and files selection alone. But provided a means to adjust it periodically.

Two C source code programs were written while attempting to work out the file format used to create the Image.113 backup files. The rd113 program will parse backup files that are in the *.113 format. The iocfg program will display information from the *.dbf files that are in the selection database which controls the files included in the backup. iocfg was a debug aid which I include as it maybe of interest for future work, but has nothing to do with actually extracting files from an *.113 backup.

rd113 program examples

rd113 version 0.91 compiled for LINUX

usage: rd113 file-name [-c] [-f] [-p] [-v] [-vv] [-t]
attempts to summarize or extract backup file contents

optional -c display catalog from uncompressed file
optional -f set flag to force uncompressed file mode
optional -p set xtract , so only extract files at of below this
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 -p is also setbash-4.2# 

Above is the usage screen for this program if no arguments are given on the command line. The first argument must be a file name containing a file header that conforms to the *.113 file format. Ie it begins with the long signature value 0xAA55AA55.

If the source backup file passes this test rd113 then checks the first 8 bytes of the 4th file block at offset 0x15C00 to determine if the file is compressed. If compressed the headers for the compressed blocks will be displayed, but at this time the compression method has not been identified and the program will then exit. The current program was written using sample files from single disk backups. As detailed in Iomega 113 Backup File Format, only the first disk of a multi disk backup is formated with eight zero bytes at 0x115c00 for a compressed file, subsequent disks have none zero values.

If the disk file in question is known to contain uncompressed backup date, but is not the 1st disk in the file set, use the -f option. This forces uncompressed mode parsing and searchs for the first DIR_SIG == 0x33CC33CC after the start of data to begin the data parse. This is a temporary work around to validate multi-media disk backups and allow recovery when all media disks in data set are not retained. Typically in a multi media disk set the data is just appended to the file, if it runs out of space in the middle of writing a file it just reopens another file and starts appending data where it left off in the previous file. The current algorithm requires the data to start with the DIR_SIG = 0x33CC33CC and terminate with the FILE_SIG = 0x66996699. If these are not found (which is unlikely in a multi media disk image) and error occurs in the preceding file and the next disk image file will skip the remainder of the data when -f is used. So typically one looses one file with this work around.

If its an uncompressed backup file the data in the files region of the archive which starts at offset 0x15C00 will be displayed. If the -x command line option has been used files will also be extracted as they are displayed.

The default behavior if just a valid file name is given is to display a listing of the data which maybe directory and/or file entries from the file data region in the backup. Use the -c option to list the catalog. In this case the program looks for a valid catalog region and displays it if found.

The -v option sets verbose mode. This displays additional data for each entry when the main files data region is being displayed. It has no effect on the display of catalog data.
the -vv option

-x and -p are used by the extraction logic. Therefore they only work with uncompressed files! -x sets extraction mode while the default is just to list the file data. If -p is not used rd113 attempts to extract all files in the backup to the pseudo drives trees that are created in the current directory. -p maybe used to limit the files extracted to those in or below any paths in the backup that are in or below a path in the backup the is a string match with the string that follow the '-p' argument.
For example supposed the backup file 'Image.113' contains several files in c:\inet\html\data1 and more in c:\inet\html\data2.
The command 'rd113 Image.113 -x -pc:\inet\ht' would create the subdirectories required for the two target directories and populate them with their files resulting in the following paths in the current directory:
c_\inet\html\data1 and c_\inet\html\data2.
The -p option expects the path in the DOS format as shown above where the separator character is '\'. If compiled for linux you need to supply two back slash char for each in the dos path, ie in linux you need to type '-pc:\\inet\\ht' to create the path string above.
Note the data is written to the pseudo drive C_ not C: and if linux was the target operating system the path separators would be changed to '/' before writting the data to disk. This was done for simplicity, and because at this late date I assume you are not really restoring the data to the same drive you originally backed up. This pseudo drive substitution occurs if you are extracting all files or just a subtree.

The -t option is another debug aid, and not intended for casual use. It runs some comparative tests on the data in my struct dir_head.
-t by itself causes the program to allocate a dynamic list of the entries. -t1 compares all records in the backup data region to find identical fields.
-t2 compares all records in the catalog region to find identical fields
-t3 comparse the catalog records to the data region records
It turns out the catalog records and the data region records are nearly identical differing only in the last value in the last record.

If you really want to understand options -vv or -t look at the source code.

iocfg program examples

iocfg version 0.91 compiled for LINUX                                               

usage: iocfg ? [-d]
where ? maybe '1' to '4' for one of *.dbf
        1: fileinfo.dbf  2: files.dbf  3: tapes.dbf  4: volumes.dbf
  use '5' to parse version 4.4 '1-STEP.FSS'
       or 'a' for all *.dbf,
       or 'b#' to summarize backup # in volumes.dbf
       or 'f#' to find VOL_ID == # in fileinfo.dbf
       of 'fn#' to find NAME_ID == # in fileinfo.dbf 
       optional -d to display data in addition to field definitions

The usage display above is given if no input is entered. iocfg expects and least on character after the program name on the command line. Characters between '1' and '4' select one of the four know databases above for display. Entering 'a' or 'A' selects all four files. By default it displays the fields in each record for the selected files and exits.
If the optional string '-d' is appended to the command line the data in each of the records is displayed. See the 113 file format page for more information the content of these *.dbf files.

slib program

This is a fringe program I developed while looking at the downloadable distribution programs for 1-Step Backup versions 4.1 and 4.4. These appear to be old Install Shield installers. One can view and extract the contents with pkunzip. The executables and *.dll files installed are contains in compressed containers typically called *.lib files. I got interested in these so I could look at the installation timestamps. slib displays the contents of the container file with timestamps. I don't know how to decompress them, but viewing the contents is a little interesting.
useage: slib &ltfilename&gt [-v]
display contents of setup library file: &ltfilename&gt
currently only option is -v to enable verbose data display


02/16/17  original release
12/18/17  minor change to download source code archives.  Correct errors in
          linux makefile build instructions.
          Switch to *.zip archive for Win32 console applications in downloads.
03/15/19 There were major changes as I learned about incremental backups which are possible. The usage above is no longer correct. An updated 113_util.zip will be available my on downloads page later in April when I finish my taxes.
The source code currently available in downloads is dated. There has been little interest in this project but I will update as time allows. There was a real bug that two different users helped identified in the decompression algorithm which has been corrected. I am finalizing new code and documentation and will update the code and Win9X executable archives when done. One of the contributors, Ian Allison, published some source code and an analysis of the 113 compression algorithm which is an interesting read. See:
README overview of his observations. He is apparently a math guy and covers this a lot better than I could. :-)