Merging upstream version 1.17~rc1.

Signed-off-by: Daniel Baumann <mail@daniel-baumann.ch>

1 files changed, 53 insertions, 7 deletions

diff --git a/doc/lziprecover.texi b/doc/lziprecover.texi
index 08d4312..85f0385 100644
--- a/doc/lziprecover.texi
+++ b/doc/lziprecover.texi
@@ -6,8 +6,8 @@
 @finalout
 @c %**end of header
 
-@set UPDATED 16 October 2014
-@set VERSION 1.17-pre1
+@set UPDATED 21 January 2015
+@set VERSION 1.17-rc1
 
 @dircategory Data Compression
 @direntry
@@ -37,6 +37,7 @@ This manual is for Lziprecover (version @value{VERSION}, @value{UPDATED}).
 @menu
 * Introduction::           Purpose and features of lziprecover
 * Invoking lziprecover::   Command line interface
+* Data safety::            Protecting data from accidental loss
 * Repairing files::        Fixing bit-flip and similar errors
 * Merging files::          Fixing several damaged copies
 * File names::             Names of the files produced by lziprecover
@@ -48,7 +49,7 @@ This manual is for Lziprecover (version @value{VERSION}, @value{UPDATED}).
 @end menu
 
 @sp 1
-Copyright @copyright{} 2009-2014 Antonio Diaz Diaz.
+Copyright @copyright{} 2009-2015 Antonio Diaz Diaz.
 
 This manual is free documentation: you have unlimited permission
 to copy, distribute and modify it.
@@ -281,6 +282,48 @@ invalid input file, 3 for an internal consistency error (eg, bug) which
 caused lziprecover to panic.
 
 
+@node Data safety
+@chapter Protecting data from accidental loss
+@cindex data safety
+
+There are 3 main types of data corruption that may cause data loss:
+single-byte errors, multi-byte errors (generally affecting a whole
+sector in a block device), and total device failure.
+
+Lziprecover protects natively against single-byte errors
+(@pxref{Repairing files}), as long as file integrity is checked
+frequently enough that a second single-byte error does not develop in
+the same member before the first one is repaired.
+
+Lziprecover also protects against multi-byte errors (@pxref{Merging
+files}), if at least one backup copy of the file is made.
+
+The only remedy for total device failure is storing backup copies in
+separate media.
+
+How does lzip compare with gzip and bzip2 with respect to data safety?
+Lets suppose that you made a backup copy of your valuable scientific
+data, compressed it, and stored two copies on separate media. Years
+later you notice that both copies are corrupt.
+
+If you compressed with gzip and both copies suffer any damage in the
+data stream, even if it is just one altered bit, the original data can't
+be recovered.
+
+If you used bzip2, and if the file is large enough to contain more than
+one compressed data block (usually larger than 900 kB), and if no block
+is damaged in both files, then the data can be manually recovered by
+splitting the files with bzip2recover, verifying every block and then
+copying the right blocks in the right order in another file.
+
+But if you used lzip, the data can be automatically recovered as long as
+no byte is damaged in both files.
+
+Note that each error in a bzip2 file makes a whole block unusable, but
+each error in a lzip file only affects the damaged bytes, making it
+possible to recover a file with thousands of errors.
+
+
 @node Repairing files
 @chapter Repairing files
 @cindex repairing files
@@ -288,12 +331,15 @@ caused lziprecover to panic.
 Lziprecover can repair perfectly most files with small errors (up to one
 single-byte error per member), without the need of any extra redundance
 at all. If the reparation is successful, the repaired file will be
-identical bit for bit to the original.
+identical bit for bit to the original. This makes lzip files resistant
+to bit-flip, one of the most common forms of data corruption.
 
 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.
+trailer (last 8 bytes of each member). If the error is in the header it
+can be easily repaired with a text editor like GNU Moe (@pxref{File
+format}). If the error is in the member size, it is enough to ignore the
+message about @samp{bad member size} when decompressing.
 
 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
@@ -641,7 +687,7 @@ for all eternity, if not longer.
 
 If you find a bug in lziprecover, please send electronic mail to
 @email{lzip-bug@@nongnu.org}. Include the version number, which you can
-find by running @w{@samp{lziprecover --version}}.
+find by running @w{@code{lziprecover --version}}.
 
 
 @node Concept index