Hello! Since xz-devel is subscribers only, I quote your message in full and also include your test scripts as an attachment for others to see.
On 2021-01-09 Étienne Mollier wrote: > Lasse Collin, on 2021-01-09 17:38:20 +0200: > > The following patch replace -cdfq with -cdf and ignores decompressor > > exit statuses >= 128. Could someone test if it fixes the original > > bug without introducing any obvious new bugs with some of the > > supported compression tools? > > Many thanks for your work on this! I unraveled a stub of test > suite from my archives and made adaptations to try out gzip and > bzip2 in addition of xz. These tests are in attachment for your > convenience, but you may need to grab a random text file long > enough to trigger the SIGPIPE condition; the test fetches a > changelog file at a Debian specific location, which you can > otherwise download here[1]. > > [1] > https://tracker.debian.org/media/packages/x/xz-utils/changelog-5.2.5-1.0 > > I applied your patch and regenerated an xz-utils package I > installed on my system. I can see that the behavior using XZ > compressed files works as expected with regards or exit codes. > It looks good on that side to me. :) > > Comparing XZ with GZip compressed files, I see the discrepancy > in the few following cases, assuming reproducer2 is shorter than > reproducer1: > > xzcmp reproducer1.gz reproducer2.gz > xzcmp reproducer1.gz reproducer2.xz > xzcmp reproducer2.gz reproducer1.gz > xzcmp reproducer2.xz reproducer1.gz > cat reproducer2.gz | xzcmp - reproducer1.gz > cat reproducer2.xz | xzcmp - reproducer1.gz > > The pattern is very similar with BZip2 compression, as expected > I guess: > > xzcmp reproducer1.bz2 reproducer2.bz2 > xzcmp reproducer1.bz2 reproducer2.xz > xzcmp reproducer2.bz2 reproducer1.bz2 > xzcmp reproducer2.xz reproducer1.bz2 > cat reproducer2.bz2 | xzcmp - reproducer1.bz2 > cat reproducer2.xz | xzcmp - reproducer1.bz2 > > When XZ is not involved, but some foreign compression is at > play, I see a similar pattern again: > > xzcmp reproducer1.gz reproducer2.gz > xzcmp reproducer1.gz reproducer2 > xzcmp reproducer2.gz reproducer1.gz > xzcmp reproducer2 reproducer1.gz > cat reproducer2.gz | xzcmp - reproducer1.gz > cat reproducer2 | xzcmp - reproducer1.gz > > All other combinations of comparing XZ against GZip, or against > BZip2 work as expected. I'm afraid I have not tested all > combinations of non-compressed against GZip against BZip2, but I > believe the same pattern might appear similarly somehow. Thanks a lot! This is quite a thorough test already. I tried the scripts with the linked changelog and also with a bigger text file. With the patch included in my previous email the expected values match the observed values on all output lines from your test scripts, and so it would seem that the patch worked in all cases. I understand from your message that you got a different result. I wonder what would explain the difference. Your results are close to what I would expect with the "trap '' PIPE" patch. Are you sure you used the correctly patched xzcmp for testing? Otherwise I'm clueless what could explain the difference in our results. Note that these lines don't do what one might think: > cat reproducer2.gz | xzcmp - reproducer1.gz > cat reproducer2.bz2 | xzcmp - reproducer1.bz2 When reading from stdin, xzcmp/xzdiff assume that the input is either in a format that xz understands (.xz or .lzma) or that it is uncompressed. So in the above cases the compressed binary reproducer2.{gz,bz2} is compared to uncompressed reproducer1 which likely isn't what one intended to do. -- Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
testwithbz2.sh
Description: application/shellscript
testwithgz.sh
Description: application/shellscript
testwithoutxz.sh
Description: application/shellscript
xzcmp_bug_844770.sh
Description: application/shellscript
