I don't think this is new behavior.  I've known about it for at least
two-three years, anyway.  There are some patches for gzip that make it
4GB+ compliant.  I've moved to using 'compress' in many of my scripts
for this reason, but I haven't tested large files with compress on
NetBSD.

Check here for gzip patch:
http://www.gzip.org/#faq10
(maybe we should add this to the base system?)

And let me know if you have some big files to try 'compress'ing.

_Matt

On 9/18/05, Peter Seebach <seebs@plethora.net> wrote:
> For several years, I've been using amanda to make backups, with gzip to
> compress them.
>=20
> Recently, it stopped working.  Apparently, gzip will error out rather tha=
n
> indicate that the source data is greater than 4GB.
>=20
> This is new behavior, and it is very unpleasant behavior, because there
> doesn't seem to be any way to override it, let alone a way to make it be
> overridden automatically by amanda.
>=20
> I assume this is a workaround for the problem of gzip -t failing on such
> archives, but I don't think that helps much.
>=20
> It looks as though "maybe_warn" in gzip.c has the side-effect of setting =
exit
> status to zero.  Perhaps the thing to do would be to save exit status bef=
ore
> calling it, and restore it afterwards, to keep amanda from seeing this as
> a fatal error?
>=20
> -s
>