Amanda-Users

Re: tar/gzip problems on restore (CRC error, "Archive contains obsolescentbase-64 headers"...)

2004-10-13 11:10:56
Subject: Re: tar/gzip problems on restore (CRC error, "Archive contains obsolescentbase-64 headers"...)
From: Toralf Lund <toralf AT procaptura DOT com>
To: Jean-Francois Malouin <Jean-Francois.Malouin AT bic.mni.mcgill DOT ca>
Date: Wed, 13 Oct 2004 17:07:09 +0200
Jean-Francois Malouin wrote:

[ snip ]

Actually, I'm starting to suspect that gzip itself is causing the problem. Any known issues, there? The client in question does have a fairly old version, 1.2.4, I think (that's the latest one supplied by SGI, unless they have upgraded it very recently.)

Honestly, I missed the earlier post in this thread...
Which version of tar are you using? I've used the SGI provided gzip
for a long time and never experienced that behaviour...

#~> /usr/sbin/gzip -h
gzip 1.2.4 (18 Aug 93)

#~> uname -R
6.5 6.5.19f

[...snip...]

The fun part here is that I have two different tars and two different gzips - the ones supplied with the OS and "SGI freeware" variants installed on /usr/freeware (dowloaded from http://freeware.sgi.com/)

Both incarnations of gzip return the same version string as the one you included above

/usr/freeware/bin/tar is

tar (GNU tar) 1.13.25


Not sure how to get version string from /usr/bin/tar, but I have

# uname -R
6.5 6.5.16f

Based on the dump file headers, I would assume that /usr/freeware variants are used for both tar and gzip. Actually, maybe that one is *required* by Amanda, since it wants GNU tar, and the one on /usr/bin is not, as far as I can tell. Perhaps there wasn't really any point in installing "freeware" version of gzip, or will Amanda make assumptions about binary locations?

- T

jf