Gene Heskett wrote:

On Wednesday 13 October 2004 11:07, Toralf Lund wrote:

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

You can tell amanda in the ./configuration options given,

where the correct tar actually lives and it will be hardcoded into it. And to get the version from the other tar, "/usr/bin/tar --version" should work,

Nope. This is not GNU tar at all. But I'm fairly sure it isn't used...

and if its not 1.13-19 or newer, use the other one that is -25 on your system.

Also, the gzip here is 1.3.3, dated in 2002. There may have been fixes to it, probably in the >2GB file sizes areas.