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
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