Re: Docs still unclear on integrity

[Antonio Diaz Diaz]

Hi Askar,

Askar Safin wrote:
> Hi. I installed lzip 1.23-3 to my debian from debian repo. Is it true
> that default decompression mode (i. e. lzip -d file.lz) verifies
> archive? "man lzip" doesn't say anything about this.

Thanks for reporting this. I have just extended the description of '-d, 
--decompress' in the man page to
  "decompress, test compressed file integrity"
and have made a similar change to the info manual.

> Also, is it true that compressed file truncation is absolutely always
> detected? (Multiply bit flips are hard to detect with absolute
> guarantee, but I think it is quite possible to always detect file
> truncation.) Is file truncation detected in default mode (lzip -d
> file.lz)? "man lzip" is silent on this

File truncation is always detected if it happens inside a member, but it 
can't be detected if it happens just after the end of a member. This is a 
well-known limitation[1] of any tool that allows file concatenation (gzip, 
bzip2, lzip, and even tar):

$ echo foo | lzip > foo.lz
$ echo bar | lzip > bar.lz
$ tar -c foo.lz bar.lz | dd bs=512 count=4 2>/dev/null | tar -t ; echo $?
foo.lz
bar.lz
0

If you want to be sure that file truncation is always detected, you may 
either use single-member files, or append some trailing data[2] to the file 
and then verify it at the receiving side. For example you may append the 
size of the whole concatenated file and verify it against the compressed 
size shown by --list:

$ lziprecover --strip=tdata foo.lz bar.lz > foobar.lz
$ wc -c < foobar.lz >> foobar.lz
$ lzip --verbose --list foobar.lz
   dict   memb  trail   uncompressed     compressed   saved  name
   4 KiB     2      3              8             80 -900.00%  foobar.lz
$ lziprecover --dump=tdata foobar.lz
80

Best regards,
Antonio.

[1] http://www.nongnu.org/lzip/manual/lziprecover_manual.html#Unzcrash
If the decompressor returns with zero status, unzcrash compares the output 
of the decompressor for the original and corrupt files. If the outputs 
differ, it means that the decompressor returned a false negative; it failed 
to recognize the corruption and produced garbage output. The only exception 
is when a multimember file is truncated just after the last byte of a 
member, producing a shorter but valid compressed file.

[2] http://www.nongnu.org/lzip/manual/lziprecover_manual.html#Trailing-data