On Wed Sep 24, 2003 @ 7:41pm, Robert Dege said:
> /bin/gtar -> /bin/tar, as it does on all the other machines. If that were
> the case, wouldn't it have problems performing the backup, or is that mixed
> in with runtar?
> > Skipped bast._devel_digital.20030903.1 (** Cannot do /bin/gtar dumps)
Robert,
If you look at your amverify (just a sh script), you'll see what must
be going on (examples from *my* 2.4.2p2 amverify, and so will vary in
detail, code drastically edited for brevity):
TAR=/usr/local/bin/tar
doonefile() {
HEADER=`$DD bs=512 count=64 | ( sed 1q ; cat > /dev/null )`
set X $HEADER
if [ X"$1" = X"program" -a X"$2" != X"" ]; then
if [ X"$TAR" != X"" -a X"$2" = X"$TAR" ]; then
CMD=$TAR
ARGS="tf -"
elif [ X"$TAR" != X"" \
-a X`basename $2` = X`basename $TAR` ]; then
CMD=$TAR
ARGS="tf -"
else
echo "** Cannot do $2 dumps" > $TEMP/errors
result=999 # flag as not really an error
So it reads the dump header, where it expects to find a dump program
listed for that dump. In your case it is finding "/bin/gtar".
Then it sees if that:
exactly matches $TAR (set at configure time), or
last path element exactly matches the last path element in TAR
(hoping for the best here), else,
generates the error message and doesn't do the verify.
So on this one box, there must be a mismatch between $TAR set in
amverify, and the program value written by amdump (or somebody) in the
dump header. Something not-quite-right about the installation. You
can just jam the TAR= line in amverify to work around it.
BTW, the 2.4.4 amverify has this section reworked a fair bit to be more
tolerant, so you're not the only person this ever happened to... :-).
--
Jay Lessert jay_lessert AT accelerant DOT net
Accelerant Networks Inc. (voice)1.503.439.3461
Beaverton OR, USA (fax)1.503.466.9472
|