Web lists-archives.com

Bug in lrzip 0.631-1 (32 bit version) with -d -o - options




Hi!

The 32 bit version of lrzip 0.631-1 contains a bug that corrupts the
decompressed dat in some circumstances.

I reproduced the problem on 2 PCs (the md5sum of the broken output was
the same on both systems).

I seems to happen when the (de)compressed file size is bigger than the
available RAM (note that the 32 bit version uses max 4GB in any case)
and lrzip resorts to using a temporary file.

See below for reproducing:

$ lrzip -i sda.img.lrz2
sda.img.lrz2:
lrzip version: 0.6 file
Compression: rzip + lzma
Decompressed file size: 64017212928
Compressed file size: 7210541304
Compression ratio: 8.878
MD5 used for integrity testing
MD5: 6594f5b0d22efd345003260054165842

$ date; df -h ; TMP=/cygdrive/i/t/tmp/  lrzip -v  -d  -o -
sda.img.lrz2  | tee >(md5sum --tag) >(sha1sum --tag) > /dev/null   ;
date
Tue Jan 24 21:29:01 CET 2017
Filesystem      Size  Used Avail Use% Mounted on
C:/cygwin       114G   94G   21G  83% /
D:              541G  534G  7.1G  99% /cygdrive/d
I:              391G  279G  113G  72% /cygdrive/i
Q:               60G   57G  2.8G  96% /cygdrive/q
The following options are in effect for this DECOMPRESSION.
Threading is ENABLED. Number of CPUs detected: 4
Detected 17160601600 bytes ram
Compression level 7
Nice Value: 19
Show Progress
Verbose
Output Filename Specified: -
Temporary Directory set as: /cygdrive/i/t/tmp/
Outputting to stdout.
Detected lrzip version 0.6 file.
MD5 being used for integrity testing.
Decompressing...
Unable to decompress entirely in ram, will use physical files
Dumping temporary file to control->outFILE.

[1]+  Stopped                 TMP=/cygdrive/i/t/tmp/ lrzip -v -d -o -
sda.img.lrz2 | tee >(md5sum --tag) >(sha1sum --tag) > /dev/null
Tue Jan 24 21:31:39 CET 2017

stein@hofer8 /cygdrive/i/Zotac_bak
$ fg
TMP=/cygdrive/i/t/tmp/ lrzip -v -d -o - sda.img.lrz2 | tee >(md5sum
--tag) >(sha1sum --tag) > /dev/null
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.

Average DeCompression Speed:  0.668MB/s
Dumping temporary file to control->outFILE.
[OK] - 64017212928 bytes
Total time: 25:22:26.25
SHA1 (-) = 6c519210541eb128c03b7c0f803adb2b46ee2a72
MD5 (-) = 8bd6ad48f2cea6a710af70b434d57673


The correct md5sum is 6594f5b0d22efd345003260054165842.


Simply decompressing the file (lrzip -d -o sda.img sda.img.lrz2) to
filesystem works fine, only when piped to stdout the problem happens.

The 64 bit version does not have this problem.


I will check if the same problem happens with the native linux build
of lrzip (it takes a day...).


I tried to reproduce the problem with a smaller file, but there it did
not happen. Maybe my first test file has some corruption that causes
this (unlikely).

Some version information (complete cygcheck -s -v -r output attached):

base-cygwin                           3.8-1
cygwin                                2.6.1-1
lrzip                                 0.631-1

Regards,
David

Attachment: cygcheck.out
Description: Binary data

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple