X-debbugs-Cc: bug-gzip@gnu.org, p...@cpan.org
Package: gzip
Version: 1.3.12-9
Severity: minor
We see
gzip: myfile: decompression OK, trailing garbage ignored
We think "Huh? What trailing garbage? What byte did it start at? I want
to investigate."
However unlike iconv(1), which when used without -c will tell you
exactly what byte problems were encountered, gunzip, gzip -l --test
--verbose etc. won't!
We see
CAVEATS
When writing compressed data to a tape, it is generally necessary to pad
the output with zeroes up to
a block boundary. When the data is read and the whole block is passed to
gunzip for decompression,
gunzip detects that there is extra trailing garbage after the
compressed data and emits a warning by
default.
OK, but do say what byte it started at, so that we can be sure.
(We can't just gunzip, then gzip back up again to compare the difference
with the orignal, as there are too many factors to make the whole file
different.)
Of course if there were an option to print out the exact switches a
file.gz was made with, maybe we could.)
P.S., the man page gives no idea who to report bugs to. It also says
"local" on it. OK, I found something in /usr/share/doc/gzip.
(P.S., I could have used IO::Uncompress::AnyUncompress to figure out what
that trailing garbage was, but after an hour of pondering that man page,
I gave up. Too complicated for me.)
