Hi,
While fiddling around with some firmware images I ran into this bug.
Basically I was trying to binary search for the end of the gzip part
but the search was always of.
When the input to gunzip is zip-size+1byte long gunzip always returns
"unexpected end of file" instead of "decompression OK,
Paul Eggert wrote:
>That's odd. I can't reproduce the problem on Fedora 17,
>with either the bundled gzip (1.4) or with
>gzip 1.5 (which I built myself). For example:
>
>$ rm test.gz x.gz
>$ : | gzip >test.gz
>$ dd if=/dev/zero bs=1 count=77 >> test.gz
>77+0 records in
>77+0 records out
>77 byte
On Fri, May 10, 2013 at 11:34 PM, Paul Eggert wrote:
> That's odd. I can't reproduce the problem on Fedora 17,
> with either the bundled gzip (1.4) or with
> gzip 1.5 (which I built myself). For example:
Just download the Fedora 17 live CD and tested it in VirtualBox.
When appending /dev/zero
On Sun, May 12, 2013 at 4:49 AM, Paul Eggert wrote:
> Ah, OK, if I'm understanding you correctly, the problem
> is merely the wording of the diagnostics. Sometimes gzip is
> saying "trailing garbage ignored", sometimes "unexpected EOF".
> This has to do with, internally, how it looks for the gzip
