DragonFly bugs List (threaded) for 2009-03
DragonFly BSD
DragonFly bugs List (threaded) for 2009-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: The problem with gzip(1)

From: Xin LI <delphij@xxxxxxxxxxx>
Date: Tue, 03 Mar 2009 10:29:35 -0800

Hash: SHA1

Hi, Hasso,

Hasso Tepper wrote:
> Our gzip(1) has a trouble unpacking lokigames/idsoftware etc archives (a 
> shell script and tar.gz in one file) making these packages fail in 
> pkgsrc. The main trouble is that it's not gzip(1) itself and probably not 
> libz either that causes the problem, but something else. I have exactly 
> the same problem with GNU gzip from pkgsrc in DragonFly, but GNU gzip 
> works just fine with these archives on every other platform I have access 
> to. Our tar doesn't have problem either with these files (not using gzip, 
> but libz directly).
> Finding out what exactly causes it is beyond my skills at the moment ...
> The testcase:
> $ fetch \
> ftp://ftp.estpak.ee/pub/FreeBSD/ports/distfiles/linuxq3apoint-1.32b.x86.run
> $ sed '1,265d' linuxq3apoint-1.32b.x86.run | gzip -cd > /dev/null
> gzip: input not gziped (MAGIC0)
> $
> $ sed '1,265d' linuxq3apoint-1.32b.x86.run | /usr/pkg/bin/gzip -cd \ 
>> /dev/null
> gzip: stdin: unexpected end of file

NetBSD r1.87 of src/usr.bin/gzip/gzip.c would give a better chance (you
would probably also want 1.88) for gzip(1) to survive with such archive
(issue a warning, but not give a fail case).  FWIW FreeBSD's gzip is
doing it this way as well.

Personally I would be inclined to issue such warning (thus the user
would know that there is something wrong with the archive, but still
allow obtaining data) rather than just to 100% match gzip behavior.
What do you think about this case?

- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
Version: GnuPG v2.0.10 (FreeBSD)


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]