amverify try to match the name of the program with tar/gtar/gnutar.
Your /usr/local/bin/gtar should work but not /usr/local/bin/mygtar,
you must add mygtar to the list.

But this features was added after 2.4.2p2

Jean-Louis

Olivier Nicole wrote:

Hi,

This may be because I am using a prehistoric version of Amanda
(2.4.2p2) but, after I make a dump, I make a verify.

Some of the DLE cannot be verified becausethe client has been compile
to use a GNU tar that is different from the one used when compiling
the server: different meaning that the tar binary has a diferent path.

So I get the kind of following results:

Checked alhazen.desktops._home_mdailey_Projects.20060928.1
Skipped ufo1000._web.20060928.1 (** Cannot do /usr/local/bin/mygtar dumps)
Skipped mailback._usr.20060928.0 (** Cannot do /usr/local/bin/gtar dumps)
Checked alhazen.desktops._.20060928.0

- /usr/local/bin/mygtar is a tar wrapper

- mailback has been build to use /usr/local/bin/gtar instead of
  /usr/local/bin/tar

By using a tar wrapper, one could provide just any archive format he
wishes and there is no way that the good old tar on the server would

know what to do with it.

But I beleive that this is a very rare case and that for most of us,
that the client uses /bin/tar, /usr/local/bin/gtar or
/usr/local/bin/tarwrapp or whatever, the file is in tar format; so the
good old tar on the server should be able to amverify it.

And just in case the file is really not in tar format, then the verify
would issue a "Cannot do /usr/local/bin/mygtar dumps" warning. And
checking if the fileis not in tar format could be done 2 ways: with
the file(1) command or with runing tar and receiving an error.

OK, that would really improve amverify (and amrestore I beleive) if
that is not included in more recent versions of Amanda.

Best regards,

Olivier