lzip/lziprecover
1
0
Fork 0
Code Issues Activity

Merging upstream version 1.16~pre2.

Browse source 
Signed-off-by: Daniel Baumann <daniel@debian.org>
This commit is contained in:
Daniel Baumann 2025-02-21 11:20:27 +01:00
parent bfc3807823
commit 2fa5af17f3
Signed by: daniel
GPG key ID: FBB4F0E80A80222F
19 changed files with 455 additions and 205 deletions
Download patch file Download diff file Expand all files Collapse all files

25
doc/lziprecover.texi
View file

@ -6,8 +6,8 @@
@finalout
@c %**end of header
@set UPDATED 5 April 2014
@set VERSION 1.16-pre1
@set UPDATED 25 May 2014
@set VERSION 1.16-pre2
@dircategory Data Compression
@direntry
@ -278,17 +278,26 @@ caused lziprecover to panic.
@chapter Repairing files
@cindex repairing files
Lziprecover is able to repair files with small errors (up to one byte
error per member). The error may be located anywhere in the file except
in the header (first 6 bytes of each member) or in the @samp{Member
size} field of the trailer (last 8 bytes of each member). This makes
lzip files resistant to bit-flip, one of the most common forms of data
corruption.
Lziprecover is usually able to repair files with small errors (up to one
byte error per member). The error may be located anywhere in the file
except in the header (first 6 bytes of each member) or in the
@samp{Member size} field of the trailer (last 8 bytes of each member).
This makes lzip files resistant to bit-flip, one of the most common
forms of data corruption.
Bit-flip happens when one bit in the file is changed from 0 to 1 or vice
versa. It may be caused by bad RAM or even by natural radiation. I have
seen a case of bit-flip in a file stored in an USB flash drive.
Repairing a file can take some time. Small files or files with the error
located near the beginning can be repaired in a few seconds. But
repairing a large file compressed with a large dictionary size and with
the error located far from the beginning, can take hours.
On the other hand, errors located near the beginning of the file cause
much more loss of data than errors located near the end. So lziprecover
repairs more efficiently the worst errors.
@node Merging files
@chapter Merging files