1
0
Fork 0

Merging upstream version 1.25.

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

View file

@ -12,7 +12,7 @@ File: lziprecover.info, Node: Top, Next: Introduction, Up: (dir)
Lziprecover Manual
******************
This manual is for Lziprecover (version 1.25-rc1, 18 November 2024).
This manual is for Lziprecover (version 1.25, 8 January 2025).
* Menu:
@ -34,7 +34,7 @@ This manual is for Lziprecover (version 1.25-rc1, 18 November 2024).
* Concept index:: Index of concepts
Copyright (C) 2009-2024 Antonio Diaz Diaz.
Copyright (C) 2009-2025 Antonio Diaz Diaz.
This manual is free documentation: you have unlimited permission to copy,
distribute, and modify it.
@ -69,31 +69,12 @@ the 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:
* 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. *Note Data safety::.
* 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.
* Additionally the lzip reference implementation is copylefted, which
guarantees that it will remain free forever.
position of 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
@ -111,11 +92,12 @@ able to find and combine the good parts of several damaged copies.
compressors in the lzip family: lzip, plzip, minilzip/lzlib, clzip, and
pdlzip.
If the cause of file corruption is a damaged medium, the combination
GNU ddrescue + lziprecover is the recommended option for recovering data
from damaged files. *Note ddrescue-example::, *note ddrescue-example2::, and
*note ddrescue-example3::, for examples. *Note GNU ddrescue manual:
(ddrescue)Top, for details about ddrescue.
GNU ddrescue provides data recovery capabilities which nicely complement
those of lziprecover. If the cause of file corruption is a damaged medium,
the combination GNU ddrescue + lziprecover is the recommended option for
recovering data from damaged files. *Note ddrescue-example::, *note
ddrescue-example2::, and *note ddrescue-example3::, for examples. *Note GNU
ddrescue manual: (ddrescue)Top, for details about ddrescue.
If a file is too damaged for lziprecover to repair it, all the
recoverable data in all members of the file can be extracted with the
@ -397,15 +379,15 @@ lziprecover supports the following options: *Note Argument syntax::.
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 '.fec', and files and directories named 'fec'.
symbolic links that are encountered recursively. Ignore files and
directories named 'fec' or '*[-._]fec'.
'-R'
'--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
'.fec', and files and directories named 'fec'.
recursively, following all symbolic links. Ignore files and
directories named 'fec' or '*[-._]fec'.
'-s'
'--split'
@ -691,9 +673,8 @@ POSIX recommends these conventions for command-line arguments.
* Certain options require an argument.
* 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). Thus, '-o foo' and '-ofoo' are
equivalent.
(In other words, the whitespace separating them is optional). Thus,
'-o foo' and '-ofoo' are equivalent.
* One or more options without arguments, followed by at most one option
that takes an argument, may follow a hyphen in a single token. Thus,
@ -836,8 +817,8 @@ total 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:
@ -1225,7 +1206,7 @@ payload_crc 36 + 4N 4
'fbs (coded fec_block_size)'
Number of FEC bytes per block. It is a multiple of 512 bytes between
512 bytes and 128 TiB.
512 bytes and 128 TiB. *Note fbs::.
'prodata_size'
Size of the protected file. 1 byte to 4 EiB.
@ -1271,10 +1252,12 @@ payload_crc 12 + fbs 4
(0xB3, 0x46, 0x45, 0x43).
'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.
'fbs (coded fec_block_size)'
*Note fbs::.
Number of FEC bytes per block. It is a multiple of 512 bytes between
512 bytes and 128 TiB. *Note fbs::.
'header_crc'
CRC32 of the previous fields, including magic.
@ -2033,43 +2016,43 @@ Concept index

Tag Table:
Node: Top226
Node: Introduction1535
Node: Invoking lziprecover6387
Ref: --trailing-error7308
Ref: --byte-repair8402
Ref: range-format10483
Ref: --reproduce10728
Ref: --unzcrash28455
Node: Argument syntax33048
Node: File format35005
Node: Data safety37759
Node: Merging with a backup40005
Node: Reproducing a mailbox41268
Node: Fec files43722
Node: How Reed-Solomon works45988
Node: Implementation details48159
Node: Creating fec files50224
Node: Testing with fec files51068
Node: Repairing with fec files52023
Ref: ddrescue-example52841
Node: Fec file format53351
Ref: fbs56222
Node: Repairing one byte58011
Node: Merging files60103
Ref: performance-of-merge61282
Ref: ddrescue-example262890
Node: Reproducing one sector64106
Ref: performance-of-reproduce68043
Ref: ddrescue-example370716
Node: Tarlz73135
Node: File names76808
Node: Trailing data77541
Node: Examples80854
Ref: concat-example81426
Node: Unzcrash82825
Ref: --set-byte87437
Node: Problems89295
Node: Concept index89847
Node: Introduction1529
Node: Invoking lziprecover5451
Ref: --trailing-error6372
Ref: --byte-repair7466
Ref: range-format9547
Ref: --reproduce9792
Ref: --unzcrash27483
Node: Argument syntax32076
Node: File format33987
Node: Data safety36741
Node: Merging with a backup38960
Node: Reproducing a mailbox40223
Node: Fec files42677
Node: How Reed-Solomon works44943
Node: Implementation details47114
Node: Creating fec files49179
Node: Testing with fec files50023
Node: Repairing with fec files50978
Ref: ddrescue-example51796
Node: Fec file format52306
Ref: fbs53073
Node: Repairing one byte57094
Node: Merging files59186
Ref: performance-of-merge60365
Ref: ddrescue-example261973
Node: Reproducing one sector63189
Ref: performance-of-reproduce67126
Ref: ddrescue-example369799
Node: Tarlz72218
Node: File names75891
Node: Trailing data76624
Node: Examples79937
Ref: concat-example80509
Node: Unzcrash81908
Ref: --set-byte86520
Node: Problems88378
Node: Concept index88930

End Tag Table