Your message dated Wed, 27 Dec 2017 20:48:44 +0100
with message-id <[email protected]>
and subject line Re: Bug#674172: pigz treats trailing data in ZLIB-format files
incorrectly
has caused the Debian Bug report #674172,
regarding pigz treats trailing data in ZLIB-format files incorrectly
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
674172: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674172
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: pigz
Version: 2.2.4-1
Severity: normal
Consider the following:
$ echo foo > foo
$ echo bar > bar
$ pigz -z foo
$ pigz -z bar
$ cat foo.zz bar.zz > foobar.zz
$ pigz -dc <foobar.zz
foo
bar
$
Note that decompressing the concatenation of two compressed files in
ZLIB format (-z option) gives the concatenation of the uncompressed
inputs.
The same thing works for GZIP format (without the -z option); this is
expected, as RFC 1952 says:
"A gzip file consists of a series of "members" (compressed data sets).
The format of each member is specified in the following section. The
members simply appear one after another in the file, with no
additional information before, between, or after them."
<http://tools.ietf.org/html/rfc1952#page-5>
However, for the ZLIB format, the relevant section of RFC 1950 has
"A zlib stream has the following structure:
[diagram omitted]
Any data which may appear after ADLER32 are not part of the zlib
stream."
<http://tools.ietf.org/html/rfc1950#page-4>
This suggests to me that the correct output for the last command above
should be:
$ pigz -dc <foobar.zz
foo
$
i.e. that pigz should ignore any trailing data after the first
ZLIB-compressed chunk.
--- End Message ---
--- Begin Message ---
Hallo,
* A. N. Other [Wed, May 23 2012, 03:15:27PM]:
> "A gzip file consists of a series of "members" (compressed data sets).
> The format of each member is specified in the following section. The
> members simply appear one after another in the file, with no
> additional information before, between, or after them."
> <http://tools.ietf.org/html/rfc1952#page-5>
>
> However, for the ZLIB format, the relevant section of RFC 1950 has
> "A zlib stream has the following structure:
> [diagram omitted]
> Any data which may appear after ADLER32 are not part of the zlib
> stream."
> <http://tools.ietf.org/html/rfc1950#page-4>
Nope. The description of gzip says: A parallel implementation of gzip
And so it acts like gzip. Some remark in ZLIB docs doesn't count here,
and even then my interpretation of it doesn't match yours.
If you don't like it, please carry the issue to upstream (on github) but
I wouldn't expect any other outcome there.
Regards,
Eduard.
--- End Message ---
