MSQIC
NTBKUP
In all displays below, I skip the initial descriptive data,
showing only the significant sections. I start each sample
output line below with |, in the few cases where there was
interacitive input I've enclosed it in square brackets, [].
In a number of cases output from earlier version are shown as
they were created at that time. Typically the output does not
change from one version to another, so don't be concerned.
Sample Output from MSQIC V 1.09
See the parent page for
invocation instructions, this section attempts to clarify
some of the output you may observe.
The -v option with a WinME archive, 3rootsc.qic, containing 3 devices: msqic 3rootsc.qic -v | 3rootsc - compressed |1: C: WIN |2: D: ARCHIVE |3: F: |MDID tag found at end of VTLB region => WinME format |Select one of archives above (1 - 3): [2] |start data 0xea00 start dir 0x15e00 |Label: 3rootsc - compressed |VTBL volume contains 0 logical segments |created (aprox): 11/10/2003 03:20:46 |flag 0x24: |File sets written without verification |version: 5341:49 |dir size 0x73f6 data size 0x402 |QFA physical start block 0x5 end block 0x6 |compression byte 0x81 |Compression used, type 0x1 |OS type: Windows 95 Since there are multiple VTBL regions, you are prompted for the one of interest. In the example above, a '2' was input producing this display. If there were only one VTBL region it would just be displayed without the query. Same archive, 3rootsc.qic, with the -fs option to find segments, still volume 2: msqic 3rootsc.qic -v |start data 0xea00 start dir 0x15e00 |Found what looks like a valid segment chain | 1: @ 0xea00 cum size = 0x0 segment size 0x402 - not compressed | 2: @ 0xee0c cum size = 0x6ff2 segment size 0x0 |end of list This is actually an example of one of the confusing things in these archives. The data region starts with a cseg_head, its byte length is 0x402. However since its a very short data region it ends in the first uncompressed segment, and the cumulative size has the word length to the next directory segment rather than 0. Below is the basic listing for the same archive and volume 2: msqic 3rootsc.qic |start data 0xea00 start dir 0x15e00 |directory display starting at offset 15e00 | |temp D 0 09/18/2003 16:15:44 attrib: 30 | |rtemu.ini 660 06/20/2003 14:45:46 attrib: 20 |end of volume directory |1 files contain 294 bytes of data, 2 directories found In this example the catalog region is parsed, there is one directory entry and one file. Below this is displayed as a tree with the -t option: msqic 3rootsc.qic -t |1 files contain 294 bytes of data, 2 directories found |ROOT | TEMP | RTEMU.INI The indentation indicates the nesting level, but it has a max of 20 spaces. The name 'ROOT' is supplied for a WIN98/WINME system. Moving on to a somewhat larger example of a compressed archive, tstbacc.qic, with the -t option: msqic tstbacc.qic -t |start data 0x100 start dir 0x2b900 |16 files contain 3c6f1 bytes of data, 3 directories found |ROOT | dos | HELP | GRAPHICS.HLP | HARDWARE.HLP | HTML.HLP | INAV.HLP | INTERNET.HLP | JAVA.HLP | LIBRARY.HLP | LUTIL.HLP | Lnotes.txt | MAC.HLP | MSCPORT.txt | java-ref.htm | lin-port.txt | linux.hlp | linux1.hlp | msvc.txt alternative listings include the directory only display: msqic tstbacc.qic -td |16 files contain 3c6f1 bytes of data, 3 directories found |Listing of directory tree, no FILES displayed |ROOT | DOS | HELP Or including the segment information: msqic tstbacc.qic -td |16 files contain 3c6f1 bytes of data, 3 directories found |ROOT 0:0 | DOS 0:d4 | HELP 0:14e | GRAPHICS.HLP 0:1f8 | HARDWARE.HLP 1:413 | HTML.HLP 1:6fcf | INAV.HLP 2:501 | INTERNET.HLP 2:1ffb | JAVA.HLP 2:6900 | LIBRARY.HLP 3:3c82 | LUTIL.HLP 3:417e | LNOTES.TXT 4:719 | MAC.HLP 4:6fba | MSCPORT.TXT 5:5725 | JAVA-REF.HTM 5:5dc0 | LIN-PORT.TXT 5:63d6 | LINUX.HLP 5:686b | LINUX1.HLP 6:616 | MSVC.TXT 7:4ff6 This is a larger, but single volume archive. The displays above require the catalog information. The last shows the segment and offset information based on the catalog, ie where the files would be located if one decompressed the archive. The physical archive in question is compressed and as desribed below only contains six segments which expand to eight when decompressed. However even if the catalog we missing or corrupted you could determine the compressed archive contains six data segments, the first (per WINME) is not compressed, and the remainder are compressed as indictated by the -fs option below: msqic tstbacc.qic -fs |start data 0x100 start dir 0x2b900 |Found what looks like a valid segment chain | 1: @ 0x100 cum size = 0x0 segment size 0x73f6 - not compressed | 2: @ 0x7500 cum size = 0x73f6 segment size 0x73f6 | 3: @ 0xe900 cum size = 0x13677 segment size 0x73f6 | 4: @ 0x15d00 cum size = 0x1f818 segment size 0x73f6 | 5: @ 0x1d100 cum size = 0x2b38c segment size 0x73f6 | 6: @ 0x24500 cum size = 0x37baf segment size 0x73ea | 7: @ 0x2b8f4 cum size = 0x0 segment size 0x0 |end of list Note each segment has a size of 0x73f6 except for the last which is followed by the terminating cseg_head. In the next example I decompress the last 2 segments, #5 and #6 above: msqic tstbacc.qic -d:15d00:3 |start data 0x100 start dir 0x2b900 | Attempt to read 0x3 continguous segments | |seg start 15d00 seg size 73f6 |found compression terminator in byte stream at 0x1d0f5 |read 0x73eb input bytes, generated 0xbb74 output bytes | |seg start 1d100 seg size 73f6 |found compression terminator in byte stream at 0x244f3 |read 0x73e9 input bytes, generated 0xc823 output bytes | |seg start 24500 seg size 73ea |found compression terminator in byte stream at 0x27ad0 |read 0x35c6 input bytes, generated 0x56ac output bytes This starts at 0x15d00, reads the cseg_head and calls the decompression routine. There are three calls to this routine, the display indicates where the decompression terminator was found as well as the number of input and output bytes. Output is written to the file 'dcomp.out'. After this routine completes dcomp.out is 0x1da43 bytes long, ie the sum of the output bytes: 0xbb74 + 0xc823 + 0x56ac. The sum of the input bytes is 0x11d9a=0x73eb+0x73e9+0x35c6. Note this implies a compression ratio of 1.66. Note the difference between the cum size of segment #6 above and segment #5 is the number of output bytes, 0xc823. You can now list or extract files from this portion of the decompressed archive with the -r option. First we list them, note responce to the prompts in '[N]' below which are required since there is no VTBL associated with this archive fragment: msqic dcomp.out -r |error reading VTBL region |start data 0x0 start dir 0x1da43 |failed to find a valid vtbl, try using -sc and -sd? |DATA recovery options: | Default is Win98 format, use Win95 instead (Y/N)? [N] | Default displays files, extract them (Y/N)? [N] |@47a2 Path: \dos\HELP | MAC.HLP est length 23237 |@a30d Path: \dos\HELP | MSCPORT.TXT est length 1521 |@a9a8 Path: \dos\HELP | JAVA-REF.HTM est length 1388 |@afbe Path: \dos\HELP | LIN-PORT.TXT est length 1015 |@b453 Path: \dos\HELP | LINUX.HLP est length 4361 |@c5fe Path: \dos\HELP | LINUX1.HLP est length 48454 |@183de Path: \dos\HELP |Searched to EOF with no next DAT_SIG, use end data region 1da43 | MSVC.TXT est length 22117 |7 potential files, 7 parsed file names Note the warning ahead of MSVC.TXT. This was the last decompressed file, no data follows it. Therefore there is no DAT_SIG which is normally used to determine in end of file with the -r option. Since its also EOF, the file would extract correctly. If one had choosen to extract the files, there would be an additional interactive prompt asking if there should be a query to confirm each extraction. Finally an example of the -p option. Note that the @ option is similar except it uses a command file, accepts multiple lines of instructions, and each line may have a destination path. Both options require paths which contain white space to be quoted. The archive has the same structure as the one about but was not compressed. msqic tstbacu.qic -pROOT+ |16 files contain 3c6f1 bytes of data, 3 directories found |Doing Redirectable path based extract with 1 source paths |Successful extraction [repeats of line above for all 16 files] |Successful extraction | extracted 16 files On completion the subdirectories DOS\HELP have been created (if they did no already exist) below the current directory and all the files were extracted to this new directory. If you had used -pROOT* the files would only have been extracted if DOS\HELP existed. If you had used -pROOT\, no files would have been extracted because you told it not to do nested sub-directories and ROOT contains no files. If it had been a compressed archive the message "Successful extraction" would be replaced by messages similar to the one below indicating the details of the decompression required to extract the file. Decompression is a bit costly on a file by file basis, so one might do better decompressing the entire file first. |found compression terminator in byte stream at 0xe8f3 |read 0x73e9 input bytes, generated 0xc281 output bytes |Decompressed 1 segments to temp working file |Successful extraction One word of caution, msqic is currently a little dumb about creating sub-directories via '+'. Currently if a directory to be created exists it aborts with a message "mkdir() failed". I'll fix this eventually, but it wants an empty subtree, or terminate your path with '*' rather than '+' and only restore to sub-directories that exist. Finally an example specific to a *.qic file with a corrupted header region. These interactive options were added in version 1.11. The -fs option will now interactively prompt for user input of 'Y' or 'N' to continue a search as indicated below. The first example is an intact archive with three volumes. This example shows how the ver 1.11 will step through the segment chain. I started with the first segment by choosing 1 after issuing the command: msqic 3rootsc.qic -fs MSQIC Ver 1.11 compiled for MSDOS 3rootsc - compressed 1: C: WIN 2: D: ARCHIVE 3: F: MDID tag found at end of VTLB region => WinME format Select one of archives above (1 - 3): [1] start data 0x200 start dir 0x7600 Found what looks like a valid segment chain 1: @ 0x200 cum size = 0x0 segment size 0x35d - not compressed 2: @ 0x567 cum size = 0x7097 segment size 0x0 end of current list, try to step into next? (Y/N) Catalog expected at 0x7600 len 0x346 Advance to 0xea00 for next segment chain 3: @ 0xea00 cum size = 0x0 segment size 0x402 - not compressed 4: @ 0xee0c cum size = 0x6ff2 segment size 0x0 end of current list, try to step into next? (Y/N) Catalog expected at 0x15e00 len 0x334 Advance to 0x1d200 for next segment chain 5: @ 0x1d200 cum size = 0x0 segment size 0x3e4 - not compressed 6: @ 0x1d5ee cum size = 0x7010 segment size 0x0 end of current list, try to step into next? (Y/N) Catalog expected at 0x24600 len 0x334 Advance to 0x2ba00 for next segment chain never found an end segment --------------------------------------- You will only see the behavior below if your VTBL is corrupt. If the VTBL is in tact it is handled automatically. I intentionally corrupted the test archive above by nulling out the VTBL region. Then ran Ver 1.11 to to verify this. To generate output identical to the segment list above: msqic 3rootsc.qic -sd200 -fs The segment list can be used to find where the different sections of the data start in the archive. The use -sd and -D to decompress starting at this location. To decompress the first volume, C: WIN: msqic 3rootsc.qic -sd200 -D Note it is critical that the -sd### option preceed the 2nd option, order matters! In a corrupted archive where it can't find a valid VTBL region, it displays interactive prompts. I show typical replies to these prompts in brackets, []: error reading VTBL region start data 0x0 start dir 0x2ba00 failed to find a valid vtbl, try using -sc and -sd? Continue with invalid VTBL? (Y/N) [y] VTBL memory image has been cleared, Win95 output format is set The offsets for data and catalog set will be obtained from -sd and -sc if the -sd option is omitted the catalog is assumed to follow last data segment Default is WINME format, ie first segment of each volume's data not compressed Is this actually WIN95 format - ie no MDID region (Y/N) [n] What date would you like displayed (format mon/day/year): [5/3/04] Force data compression flag? (Y/N) [y] Device Lable (max 15 chars): [C: WIN] Description (max 43 chars): [Trial decompression for corrupted archive] ESC to abort, 'N' repeat above, or 'Y' to use above: [y] -------------------- Note you must tell it whether its a compressed archive and whether it is Win95 format, no MDID, or Win98 and WinME format with the MDID region as the layout of the data region is slightly different in these version. The generic command line to decompress an archive (or portion of one if its a multi volume WINME format archive) is shown below: msqic-sd### -D replace with your file name and ### with the hex offset in the file where the first segment header occurs. See the notes in the main documentation for methods to find this, ie -fs or -fd. After decompressing the archive, you can go back and use msqic on the output file, dcomp.out, to extract any files of interest.
ntbkup backup.bkf
|TAPE found keyword at offset 0
|backup.bkf ....
|MTF Media Label|1.0|Seagate|NTBackup5.0| .....
|Sicherungsprogramm (NTBACKUP.EXE) Version 1.0 Rev. 3.41 ....
|SFMB found keyword at offset 400
|SSET found keyword at offset 800 blk = 2
|Set 1:
|Name: Satz am 27.12.2003 um 21:23 erstellt
|Description:
|User: LAPTOP\Wolfgang Keller
|
|VOLB found keyword at offset c00
|device name: C:
|DIRB found keyword at offset 1000 1st Stream: NACL
|Dir Name[12]: \test1\
|FILE found keyword at offset 1400 data from 1536 to 1552
|DIRB found keyword at offset 1800 1st Stream: NACL
|Dir Name[24]: \test1\test2\
|FILE found keyword at offset 1c00 data from 1d36 to 1d58
|DIRB found keyword at offset 2000 1st Stream: NACL
|Dir Name[36]: \test1\test2\test3\
|FILE found keyword at offset 2400 data from 2536 to 255e
|SFMB found keyword at offset 2800
|ESET found keyword at offset 2c00
|TFDD found keyword at offset 3000
|TSMP found keyword at offset 3400
|ESET found keyword at offset 3800
|SFMB found keyword at offset 3c00
Above is the raw listing of tags, whic is produce with no optional arguments.
The remaining examples below are done with this archive and one or more
optional command line arguments. All displays would begin with the following
a subset of the tag information above:
|NTBKUP Ver 1.03 compiled for WIN32 compiled for 64 bit file offsets
|Copyright (C) 2003 William T. Kranz
|NTBKUP comes with ABSOLUTELY NO WARRANTY
|Free software distributed under the terms of the GNU General Public license
|See http://www.gnu.org/licenses/gpl.html for license information
|Check http://www.fpns.net/willy/index.html for Updates & Documentation
|
|Set 1:
|Name: Satz am 27.12.2003 um 21:23 erstellt
|Description:
|User: LAPTOP\Wolfgang Keller
|
|device name: C:
Supplemental output for tree display via -d:
ntbkup backup.bkf -d
|C:
| \test1\
| \test1\test2\
| \test1\test2\test3\
Per above, the archive contains 3 nested directories. Each
contains a single file. Below the supplemental output for a
couple of the command line options to extract the files are shown.
ntbkup backup.bkf -x
This command would extract all files to the current directory, ie
3 files would be extracted:
|Dir Name[12]: \test1\ data from 1536 to 1552
|length 28 atrib 0x20 12/27/2003 09:19:52 PM
|extracing: test1.txt:
|
|Dir Name[24]: \test1\test2\ data from 1d36 to 1d58
|length 34 atrib 0x20 12/27/2003 09:20:47 PM
|extracing: test2.txt:
|
|Dir Name[36]: \test1\test2\test3\ data from 2536 to 255e
|length 40 atrib 0x20 12/27/2003 09:21:41 PM
|extracing: test3.txt:
ntbkup backup.bkf -xtest2.txt
This command would only extract test2.txt as its the only one that
matches the filter.
ntbkup backup.bkf -x -l\test1\test2\
This command would have the same result, it attempts to extract all
the files from the \test1\test2 directory which only contains test2.txt:
(Note the trailing '\' after test2 is option in this case and no Drive letter!)
|Dir Name[12]: \test1\
|Dir Name[24]: \test1\test2\ data from 1d36 to 1d58
|length 34 atrib 0x20 12/27/2003 09:20:47 PM
|extracing: test2.txt:
|
|Dir Name[36]: \test1\test2\test3\
ntbkup backup.bkf -pC:\test1\test2\
This command would again have the same result. The trailing '\' is required
to indicate only files from the test2 directory are to be extracted. The
drive letter is also required to match the output generated by the -d option.
I got a query from Chris, who has spaces in his directory name.
Suppose you wanted to extract from a backup of "\My Documents"
You could use either of the following to get just the *.txt files
in this directory:
ntbkup backup.bkf -x*.txt -l"\My Documents"
or
ntbkup backup.bkf -x*.txt -l"\My Documents\\"
I find the 2nd example above a little odd, an possibly it is
an artifact of my WinME system. However the command processor
passes the first '\' after the quoate to my program, but
treats the trailing slashes as a single one. Ie if I
input "\My Documents\" it gives My Documents" to
the program as the input string. Confusing, it forces the
trailing quoate to a literal char in this case. The safest solution
appears to be to NOT include the trailing '\' and let the
program provide it for you (which it does).
ntbkup backup.bkf -pC:\test1\test2+
This command extracts two files, test2.txt and test3.txt as it extracts
all files from and below \test1\test2\. Note that it will create subdirectories
as required. The files from test2 are put into the current directory, but
subdirectories are created if they don't exist.
The related options would be
ntbkup backup.bkf -pC:\test1\test2*
Above only extracts files into subdirectories that exist on target system.
This can be used as an alternative filtering system
ntbkup backup.bkf -pC:\test1\test2\
Above just extracts files from test2 to the current directory and creates
no new directories.
In general the -p and @ options for ntbkup have not been rigorously tested.
They worked in my simple test cases, but if you don't have luck with them
fall back on the -x -l combinations to get your data.
The @ option uses a command file. Its similar to the -p option, but
requires both a source directory in the archive and a destination directory
on your hard drive. If you wanted to recreate the backup.bkf structure
on C: you would create a command file, extract.cmd, containg one line:
C:\test1\ c:\test1\
You would run
ntbkup backup.bkf @extract.cmd
You would see the following supplemental output:
|Doing redirect:
|Source: C:\test1\
|redirect: c:\temp\ data from 1536 to 1552
|length 28 atrib 0x20 12/27/2003 09:19:52 PM
|extracing: test1.txt:
|
|Source: C:\test1\test2\
|redirect: d:\test2\
|level 0: \test1\test2\ data from 1d36 to 1d58
|length 34 atrib 0x20 12/27/2003 09:20:47 PM
|extracing: test2.txt:
|
|level 1: \test1\test2\test3\ data from 2536 to 255e
|length 40 atrib 0x20 12/27/2003 09:21:41 PM
|extracing: test3.txt:
The real intent of the @ option is to allow you to restructure
the directories in your archive on a new hard drive.
Creating an extract.cmd with the following:
C:\test1\ C:\temp\
C:\test1\test2+ d:\test2\
And running it per above would create a similar display, but
the file from the archives test1 directory would be placed in C:\temp
which must exist. The files in and below the archives test2
directory would be placed in and below d:\test2 and the destination
directories would be created where required.
Also note that you need quoates around your extract.cmd paths
as it assumes unquoated white space delimits the archive source
path and the destination path.
WARNING
A number of people miss the fine print above. When using the -p or @ option
path specifications MUST include the drive specification. It is different
than the -l example which does not take a drive specification.
Compare the output below from the following command to the correct
syntax above:
ntbkup backup.bkf -p\test1\test2+
|device name: C:
|Doing redirect:
|Source: \test1\test2
|redirect:
|can't find source path
If you get the "can't find source path" you have either mis-typed the path,
or fogotten to include the volume specification. Until Version 1.04 I only
accepted drive letters for the volume. Turns out when done over a network
it may have a a generic network name such as "\\NETWORK DRIVE". Since version
1.04 this style of specification is also accepted. If my backup.bkf had
this specification, the following quoated string would be required:
ntbkup backup.bkf -p"\\NETWORK DRIVE\test1\test2+"
Note the quoats start after -p and end after the +
As of Version 1.05 I surpress most of the preliminary directory processing
when the -d and -p options are used. This was done to make it easier to see
the error message above "can't find source path". If you see this error message
use -d to check the paths, but be sure to include the volume specification
in the -p command.
Luck!