OffZip Decompression ATIH tib backup archive

[a1b1]

I have ATIHv14tib archives many and hope your tool can unzip them. I tried with FULL (Standalone) backup archive I made using options of the following.

Choose C: System drive - This drive has two 4K cluster Format NTFS partitons C: and D: For backup System I choose partition 1 C: only it usually has a check mark on it by default.
Set drive to backup another internal drive not this drive for speed. And set file name for the backup archive.

Other Options:
FULL Backup
Maximum Compression
Verify

I check the log after this has completed for errors. Then after restart the pc.

For some reason I cannot figure out how to decompress using offzip so the .bin image is able to be mounted or seen correctly with other softwares. Always seems to produce bad decompressed image.

So far tried with the following, none of these so far has made a working decompressed archive.

Offzip -R -a -1 -Q -z 15
Offzip -R -a -1 -Q -z -15
Offzip -R -a -1

I have also tried with differing numbers than 15 I read that numbers can be 0 to 32 but is a hit and miss and takes a while with large backup archive. Maybe useful if offzip could optimize what best number to use for difficult file with a scan mode to figure that out. That said these archives are maybe same compression as set before backup or are they variable always try to achieve Maximum compression ?


Is it me or is it offzip at fault here !

[aluigi]

Probably the backup doesn't use deflate or zlib.

It's not possible to "guess/optimize" the choose between zlib and deflate because zlib is a container of deflate data, if you have a zlib data you will dump it if you both use -z 15 and -z -15, if you have deflate data then only -z -15 will do it.

-z is referred to the windowBits field of zlib API:
https://www.zlib.net/manual.html

The windowBits parameter is the base two logarithm of the window size (the size of the history buffer). It should be in the range 8..15 for this version of the library. Larger values of this parameter result in better compression at the expense of memory usage. The default value is 15 if deflateInit is used instead.

For the current implementation of deflate(), a windowBits value of 8 (a window size of 256 bytes) is not supported. As a result, a request for 8 will result in 9 (a 512-byte window). In that case, providing 8 to inflateInit2() will result in an error when the zlib header with 9 is checked against the initialization of inflate(). The remedy is to not use 8 with deflateInit2() with this initialization, or at least in that case use 9 with inflateInit2().

windowBits can also be –8..–15 for raw deflate. In this case, -windowBits determines the window size. deflate() will then generate raw deflate data with no zlib header or trailer, and will not compute a check value.

windowBits can also be greater than 15 for optional gzip encoding. Add 16 to windowBits to write a simple gzip header and trailer around the compressed data instead of a zlib wrapper. The gzip header will have no file name, no extra data, no comment, no modification time (set to zero), no header crc, and the operating system will be set to the appropriate value, if the operating system was determined at compile time. If a gzip stream is being written, strm->adler is a CRC-32 instead of an Adler-32.

[a1b1]

about -z what I have read
-z 15 a zlib file that has headers and crc data (the file can verify itself using crc)
-z -15 a zlib raw file with no headers and crc data
-z a gzip file maybe uses a number between -z 16 to 31 to decompress.

The backup archive is a verified ATIHv14tib file, as verifiable I guess it is -z 15 (headers and crc)

offzip.exe -Q -R -a -1 -z 15 "path:\infile" "path:\outfile.bin" 0

infile - 4,246,256 (compressed ATIHv14tib backup archive source file)
outfile1 - 7,875,284
outfile2 - 2,516,067 (run with same command from outfile1 to outfile2)

Try with with option -z -15 instead of -z 15 on infile produces only errors during scanning -zlib Z_DATA_ERROR, the data in the file not in zip data format.

outfile1 doesn't mount or can be seen with drive image mount softwares as a disk. With a hex viewer outfile1 does now show the NTFS header at the start of the outfile1. With infile this is not viewable as it is compressed.

What is strange is the file sizes in that the data is not been been kept on successive scans outfile1 to outfile2. That also maybe the first scan infile to outfile1 has also lost data as happened from outfile1 to outfile2 any ideas!