diff options
Diffstat (limited to 'doc/lziprecover.texi')
| -rw-r--r-- | doc/lziprecover.texi | 25 |
1 files changed, 17 insertions, 8 deletions
diff --git a/doc/lziprecover.texi b/doc/lziprecover.texi index be4fc27..00fbc8e 100644 --- a/doc/lziprecover.texi +++ b/doc/lziprecover.texi @@ -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 |