Merging upstream version 1.25.
Signed-off-by: Daniel Baumann <daniel@debian.org>
This commit is contained in:
parent
09c9ea500b
commit
ccc1759b5f
40 changed files with 207 additions and 245 deletions
|
@ -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
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue