summaryrefslogtreecommitdiffstats
path: root/doc
diff options
context:
space:
mode:
authorDaniel Baumann <mail@daniel-baumann.ch>2015-11-07 09:58:28 +0000
committerDaniel Baumann <mail@daniel-baumann.ch>2015-11-07 09:58:28 +0000
commit8faaeaa3dfe3451b487bea5db15ba6b8970bbe74 (patch)
tree60716d12512c396abc47fece784b2685cbcabb47 /doc
parentAdding debian version 1.15~pre1-1. (diff)
downloadlzip-8faaeaa3dfe3451b487bea5db15ba6b8970bbe74.tar.xz
lzip-8faaeaa3dfe3451b487bea5db15ba6b8970bbe74.zip
Merging upstream version 1.15~pre2.
Signed-off-by: Daniel Baumann <mail@daniel-baumann.ch>
Diffstat (limited to 'doc')
-rw-r--r--doc/lzip.17
-rw-r--r--doc/lzip.info66
-rw-r--r--doc/lzip.texinfo49
3 files changed, 69 insertions, 53 deletions
diff --git a/doc/lzip.1 b/doc/lzip.1
index 0c6f516..3baec79 100644
--- a/doc/lzip.1
+++ b/doc/lzip.1
@@ -1,5 +1,5 @@
.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.37.1.
-.TH LZIP "1" "March 2013" "Lzip 1.15-pre1" "User Commands"
+.TH LZIP "1" "May 2013" "Lzip 1.15-pre2" "User Commands"
.SH NAME
Lzip \- reduces the size of files
.SH SYNOPSIS
@@ -71,6 +71,11 @@ The bidimensional parameter space of LZMA can't be mapped to a linear
scale optimal for all files. If your files are large, very repetitive,
etc, you may need to use the \fB\-\-match\-length\fR and \fB\-\-dictionary\-size\fR
options directly to achieve optimal performance.
+.PP
+Exit status: 0 for a normal exit, 1 for environmental problems (file
+not found, invalid flags, I/O errors, etc), 2 to indicate a corrupt or
+invalid input file, 3 for an internal consistency error (eg, bug) which
+caused lzip to panic.
.SH "REPORTING BUGS"
Report bugs to lzip\-bug@nongnu.org
.br
diff --git a/doc/lzip.info b/doc/lzip.info
index 5c4cf81..9c4e874 100644
--- a/doc/lzip.info
+++ b/doc/lzip.info
@@ -11,7 +11,7 @@ File: lzip.info, Node: Top, Next: Introduction, Up: (dir)
Lzip Manual
***********
-This manual is for Lzip (version 1.15-pre1, 21 March 2013).
+This manual is for Lzip (version 1.15-pre2, 11 May 2013).
* Menu:
@@ -43,6 +43,10 @@ gzip or bzip2. Lzip decompresses almost as fast as gzip and compresses
better than bzip2, which makes it well suited for software distribution
and data archiving.
+ Lzip uses the same well-defined exit status values used by bzip2,
+which makes it safer when used in pipes or scripts than compressors
+returning ambiguous warning values, like gzip.
+
If you ever need to recover data from a damaged lzip file, try the
lziprecover program.
@@ -93,20 +97,16 @@ filename.tlz becomes filename.tar
anyothername becomes anyothername.out
As a self-check for your protection, lzip stores in the member
-trailer the 32-bit CRC of the original data and the size of the
-original data, to make sure that the decompressed version of the data
-is identical to the original. This guards against corruption of the
-compressed data, and against undetected bugs in lzip (hopefully very
-unlikely). The chances of data corruption going undetected are
-microscopic, less than one chance in 4000 million for each member
-processed. Be aware, though, that the check occurs upon decompression,
-so it can only tell you that something is wrong. It can't help you
-recover the original uncompressed data.
-
- Return values: 0 for a normal exit, 1 for environmental problems
-(file not found, invalid flags, I/O errors, etc), 2 to indicate a
-corrupt or invalid input file, 3 for an internal consistency error (eg,
-bug) which caused lzip to panic.
+trailer the 32-bit CRC of the original data, the size of the original
+data and the size of the member. These values, together with the value
+remaining in the range decoder and the end-of-stream marker, provide a
+very safe 4 factor integrity checking which guarantees that the
+decompressed version of the data is identical to the original. This
+guards against corruption of the compressed data, and against
+undetected bugs in lzip (hopefully very unlikely). The chances of data
+corruption going undetected are microscopic. Be aware, though, that the
+check occurs upon decompression, so it can only tell you that something
+is wrong. It can't help you recover the original uncompressed data.

File: lzip.info, Node: Algorithm, Next: Invoking Lzip, Prev: Introduction, Up: Top
@@ -325,6 +325,12 @@ E exabyte (10^18) | Ei exbibyte (2^60)
Z zettabyte (10^21) | Zi zebibyte (2^70)
Y yottabyte (10^24) | Yi yobibyte (2^80)
+
+ Exit status: 0 for a normal exit, 1 for environmental problems (file
+not found, invalid flags, I/O errors, etc), 2 to indicate a corrupt or
+invalid input file, 3 for an internal consistency error (eg, bug) which
+caused lzip to panic.
+

File: lzip.info, Node: File Format, Next: Stream Format, Prev: Invoking Lzip, Up: Top
@@ -392,8 +398,9 @@ additional information before, between, or after them.
`Member size (8 bytes)'
Total size of the member, including header and trailer. This field
- acts as a distributed index, and facilitates safe recovery of
- undamaged members from multi-member files.
+ acts as a distributed index, allows the verification of stream
+ integrity, and facilitates safe recovery of undamaged members from
+ multi-member files.

@@ -535,8 +542,8 @@ bm_align reverse bit tree for distances >= 128, after
fixed probability bits
- There are two separated sets of length contexts (`Len_model' in the
-source). One for normal matches, the other for repeated matches. The
+ There are two separate sets of contexts for lengths (`Len_model' in
+the source). One for normal matches, the other for repeated matches. The
contexts in each Len_model are (see `decode_len' in the source):
Name Indices Used when
@@ -747,7 +754,6 @@ struct Bit_model
Bit_model() : probability( bit_model_total / 2 ) {}
};
-
struct Len_model
{
Bit_model choice1;
@@ -1057,7 +1063,7 @@ typedef uint8_t File_trailer[20];
// 12-19 member size including header and trailer
-/* Return values: 0 for a normal exit, 1 for environmental problems
+/* Exit status: 0 for a normal exit, 1 for environmental problems
(file not found, invalid flags, I/O errors, etc), 2 to indicate a
corrupt or invalid input file. */
@@ -1156,15 +1162,15 @@ Concept Index

Tag Table:
Node: Top224
-Node: Introduction1067
-Node: Algorithm4732
-Node: Invoking Lzip7250
-Node: File Format12602
-Node: Stream Format14985
-Node: Examples23695
-Node: Problems25644
-Node: Reference source code26174
-Node: Concept Index39424
+Node: Introduction1065
+Node: Algorithm4786
+Node: Invoking Lzip7304
+Node: File Format12895
+Node: Stream Format15328
+Node: Examples24042
+Node: Problems25991
+Node: Reference source code26521
+Node: Concept Index39768

End Tag Table
diff --git a/doc/lzip.texinfo b/doc/lzip.texinfo
index 632abc5..484b5ac 100644
--- a/doc/lzip.texinfo
+++ b/doc/lzip.texinfo
@@ -6,8 +6,8 @@
@finalout
@c %**end of header
-@set UPDATED 21 March 2013
-@set VERSION 1.15-pre1
+@set UPDATED 11 May 2013
+@set VERSION 1.15-pre2
@dircategory Data Compression
@direntry
@@ -64,6 +64,10 @@ gzip or bzip2. Lzip decompresses almost as fast as gzip and compresses
better than bzip2, which makes it well suited for software distribution
and data archiving.
+Lzip uses the same well-defined exit status values used by bzip2, which
+makes it safer when used in pipes or scripts than compressors returning
+ambiguous warning values, like gzip.
+
If you ever need to recover data from a damaged lzip file, try the
lziprecover program.
@@ -116,20 +120,16 @@ file from that of the compressed file as follows:
@end multitable
As a self-check for your protection, lzip stores in the member trailer
-the 32-bit CRC of the original data and the size of the original data,
-to make sure that the decompressed version of the data is identical to
-the original. This guards against corruption of the compressed data, and
-against undetected bugs in lzip (hopefully very unlikely). The chances
-of data corruption going undetected are microscopic, less than one
-chance in 4000 million for each member processed. Be aware, though, that
-the check occurs upon decompression, so it can only tell you that
-something is wrong. It can't help you recover the original uncompressed
-data.
-
-Return values: 0 for a normal exit, 1 for environmental problems (file
-not found, invalid flags, I/O errors, etc), 2 to indicate a corrupt or
-invalid input file, 3 for an internal consistency error (eg, bug) which
-caused lzip to panic.
+the 32-bit CRC of the original data, the size of the original data and
+the size of the member. These values, together with the value remaining
+in the range decoder and the end-of-stream marker, provide a very safe 4
+factor integrity checking which guarantees that the decompressed version
+of the data is identical to the original. This guards against corruption
+of the compressed data, and against undetected bugs in lzip (hopefully
+very unlikely). The chances of data corruption going undetected are
+microscopic. Be aware, though, that the check occurs upon decompression,
+so it can only tell you that something is wrong. It can't help you
+recover the original uncompressed data.
@node Algorithm
@@ -350,6 +350,12 @@ Table of SI and binary prefixes (unit multipliers):
@item Y @tab yottabyte (10^24) @tab | @tab Yi @tab yobibyte (2^80)
@end multitable
+@sp 1
+Exit status: 0 for a normal exit, 1 for environmental problems (file not
+found, invalid flags, I/O errors, etc), 2 to indicate a corrupt or
+invalid input file, 3 for an internal consistency error (eg, bug) which
+caused lzip to panic.
+
@node File Format
@chapter File Format
@@ -420,8 +426,8 @@ Size of the uncompressed original data.
@item Member size (8 bytes)
Total size of the member, including header and trailer. This field acts
-as a distributed index, and facilitates safe recovery of undamaged
-members from multi-member files.
+as a distributed index, allows the verification of stream integrity, and
+facilitates safe recovery of undamaged members from multi-member files.
@end table
@@ -572,8 +578,8 @@ fixed probability bits
@end multitable
@sp 1
-There are two separated sets of length contexts (@samp{Len_model} in the
-source). One for normal matches, the other for repeated matches. The
+There are two separate sets of contexts for lengths (@samp{Len_model} in
+the source). One for normal matches, the other for repeated matches. The
contexts in each Len_model are (see @samp{decode_len} in the source):
@multitable @columnfractions .2 .4 .4
@@ -814,7 +820,6 @@ struct Bit_model
Bit_model() : probability( bit_model_total / 2 ) {}
};
-
struct Len_model
{
Bit_model choice1;
@@ -1124,7 +1129,7 @@ typedef uint8_t File_trailer[20];
// 12-19 member size including header and trailer
-/* Return values: 0 for a normal exit, 1 for environmental problems
+/* Exit status: 0 for a normal exit, 1 for environmental problems
(file not found, invalid flags, I/O errors, etc), 2 to indicate a
corrupt or invalid input file. */