I tried the 2.7.0-0.1 test release and now the behavior changed. Before I got consistently a wrong MD5 sum of 8bd6ad48f2cea6a710af70b434d57673 With this release I get c43a02c309fa5e0abe778201e9ceec46.
So something changed. Either the problem is in cygwin or lrzip, I guess. Regards, David On 30 January 2017 at 16:23, David Balažic <xerc...@gmail.com> wrote: > I tried in Ubuntu 32 bit (both the packaged lrzip and a self compiled > one) and there the problem does not happen, so it looks like either: > - bad lrzip in cygwin > - cygwin pipe issues? > > Regards, > David > > > On 25 January 2017 at 23:15, David Balažic <xerc...@gmail.com> wrote: >> 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 -- 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