lzip/lziprecover
1
0
Fork 0
Code Issues Activity

Merging upstream version 1.25.

Browse source 
Signed-off-by: Daniel Baumann <daniel@debian.org>
This commit is contained in:
Daniel Baumann 2025-02-21 11:33:36 +01:00
parent 09c9ea500b
commit ccc1759b5f
Signed by: daniel
GPG key ID: FBB4F0E80A80222F
40 changed files with 207 additions and 245 deletions
Download patch file Download diff file Expand all files Collapse all files

74
doc/lziprecover.texi
View file

@ -6,8 +6,8 @@
@finalout
@c %**end of header
@set UPDATED 18 November 2024
@set VERSION 1.25-rc1
@set UPDATED 8 January 2025
@set VERSION 1.25
@dircategory Compression
@direntry
@ -55,7 +55,7 @@ This manual is for Lziprecover (version @value{VERSION}, @value{UPDATED}).
@end menu
@sp 1
Copyright @copyright{} 2009-2024 Antonio Diaz Diaz.
Copyright @copyright{} 2009-2025 Antonio Diaz Diaz.
This manual is free documentation: you have unlimited permission to copy,
distribute, and modify it.
@ -91,36 +91,11 @@ lzip format is extraordinarily safe. The simple and safe design of the file
format complements the embedded error detection provided by the LZMA data
stream. Any distance larger than the dictionary size acts as a forbidden
symbol, allowing the decompressor to detect the approximate position of
errors, and leaving very little work for the check sequence (CRC and data
sizes) in the detection of errors. Lzip is usually able to detect all
possible bit flips in the compressed data without resorting to the check
sequence. It would be difficult to write an automatic recovery tool like
lziprecover for the gzip format. And, as far as I know, it has never been
written.
The lzip file format is designed for data sharing and long-term archiving,
taking into account both data integrity and decoder availability:
@itemize @bullet
@item
The lzip format provides very safe integrity checking and some data
recovery means. The program lziprecover can repair bit flip errors
(one of the most common forms of data corruption) in lzip files, and
provides data recovery capabilities, including error-checked merging
of damaged copies of a file. @xref{Data safety}.
@item
The lzip format is as simple as possible (but not simpler). The lzip
manual provides the source code of a simple decompressor along with a
detailed explanation of how it works, so that with the only help of the
lzip manual it would be possible for a digital archaeologist to extract
the data from a lzip file long after quantum computers eventually
render LZMA obsolete.
@item
Additionally the lzip reference implementation is copylefted, which
guarantees that it will remain free forever.
@end itemize
errors, and leaving little work for the check sequence (CRC and data sizes)
in the detection of errors. Lzip is usually able to detect all possible bit
flips in the compressed data without resorting to the check sequence. It
would be difficult to write an automatic recovery tool like lziprecover for
the gzip format. And, as far as I know, it has never been written.
A nice feature of the lzip format is that a corrupt byte is easier to repair
the nearer it is from the beginning of the file. Therefore, with the help of
@ -138,10 +113,11 @@ Lziprecover is able to recover or decompress files produced by any of the
compressors in the lzip family: lzip, plzip, minilzip/lzlib, clzip, and
pdlzip.
If the cause of file corruption is a damaged medium, the combination
@w{GNU ddrescue + lziprecover} is the recommended option for recovering data
from damaged files. @xref{ddrescue-example}, @ref{ddrescue-example2}, and
@ref{ddrescue-example3}, for examples.
GNU ddrescue provides data recovery capabilities which nicely complement
those of lziprecover. If the cause of file corruption is a damaged medium,
the combination @w{GNU ddrescue + lziprecover} is the recommended option for
recovering data from damaged files. @xref{ddrescue-example},
@ref{ddrescue-example2}, and @ref{ddrescue-example3}, for examples.
@ifnothtml
@xref{Top,GNU ddrescue manual,,ddrescue},
@end ifnothtml
@ -447,15 +423,15 @@ Quiet operation. Suppress all messages.
When creating or reading fec files (but not when listing), for each directory
operand, read and process all files in that directory, recursively. Follow
symbolic links given in the command line, but skip symbolic links that are
encountered recursively. Ignore files with extension @file{.fec}, and files
and directories named @file{fec}.
encountered recursively. Ignore files and directories named @file{fec} or
@file{*[-._]fec}.
@item -R
@itemx --dereference-recursive
When creating or reading fec files (but not when listing), for each directory
operand, read and process all files in that directory, recursively,
following all symbolic links. Ignore files with extension @file{.fec}, and
files and directories named @file{fec}.
following all symbolic links. Ignore files and directories named @file{fec}
or @file{*[-._]fec}.
@item -s
@itemx --split
@ -741,8 +717,7 @@ POSIX recommends these conventions for command-line arguments.
@item Certain options require an argument.
@item An option and its argument may or may not appear as separate tokens.
(In other words, the whitespace separating them is optional, unless the
argument is the empty string).
(In other words, the whitespace separating them is optional).
Thus, @w{@option{-o foo}} and @option{-ofoo} are equivalent.
@item One or more options without arguments, followed by at most one option
@ -903,8 +878,8 @@ device failure is storing backup copies in separate media.
The extraordinary safety of the lzip format allows lziprecover to use the
redundance that occurs naturally when making compressed backups. Lziprecover
can recover data that would not be recoverable from files compressed in
other formats. Let's see two examples of how much better is lzip compared
with gzip and bzip2 with respect to data safety:
other formats. See these two examples of the data recovery capabilities
offered by lziprecover:
@menu
* Merging with a backup:: Recovering a file using a damaged backup
@ -1279,6 +1254,7 @@ possible:
All multibyte values are stored in little endian order except
@samp{prodata_md5}.
@anchor{fbs}
The @samp{fbs} (fec_block_size) field is coded as a little endian 16-bit
floating point unsigned integer with an 11-bit mantissa at bits 0-10 and a
5-bit exponent at bits 11-15. The mantissa is an integer between 0 and 2047.
@ -1337,10 +1313,9 @@ Bit 0 (is_crc_c): crc_array contains CRC32 (0) or CRC32-C (1).@*
Bit 1 (gf16): Galois field is GF(2^8) (0) or GF(2^16) (1).@*
Bits 2-7: zero.
@anchor{fbs}
@item fbs (coded fec_block_size)
Number of FEC bytes per block. It is a multiple of 512 bytes between 512
bytes and @w{128 TiB}.
bytes and @w{128 TiB}. @xref{fbs}.
@item prodata_size
Size of the protected file. 1 byte to @w{4 EiB}.
@ -1388,10 +1363,11 @@ A four byte string identifying the fec packet, with the value "\xB3FEC"
(0xB3, 0x46, 0x45, 0x43).
@item fbn (fec_block_number)
Number of this FEC block. Required to compute the decode matrix.
Number of this FEC block (0 to 32767). Required to compute the decode matrix.
@item fbs (coded fec_block_size)
@xref{fbs}.
Number of FEC bytes per block. It is a multiple of 512 bytes between 512
bytes and @w{128 TiB}. @xref{fbs}.
@item header_crc
CRC32 of the previous fields, including magic.