From d296515f4777d1e4b7d78e6aa8ea698162bfbc2b Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sat, 7 Nov 2015 12:52:38 +0100 Subject: Merging upstream version 1.18~pre1. Signed-off-by: Daniel Baumann --- doc/lziprecover.texi | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'doc/lziprecover.texi') diff --git a/doc/lziprecover.texi b/doc/lziprecover.texi index 3f6e0aa..29045e7 100644 --- a/doc/lziprecover.texi +++ b/doc/lziprecover.texi @@ -6,8 +6,8 @@ @finalout @c %**end of header -@set UPDATED 28 May 2015 -@set VERSION 1.17 +@set UPDATED 30 June 2015 +@set VERSION 1.18-pre1 @dircategory Data Compression @direntry @@ -302,9 +302,9 @@ 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. +Lets suppose that you made a backup 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 -- cgit v1.2.3