>It's printed in sendsize.debug, IIRC. And in runtar.debug.
>
>It will reference a gnutar-list-dir .new file. It's created initially
>empty for level 0 estimates, and a copy of the lower level for
>incremental estimates.
>
>FWIW, I've had similar results with GNU tar 1.13.19 on Solaris 7/x86.
>I've started investigating, but didn't get very far, and ended up
>downgrading back to 1.12+patches.
Hi,
I solved the problem, it was an access right permission issue that was
clearly indicated in /tmp/amanda/sendsize.*.debug
I would suggest that this debug file is mentionned in the FAQ, about
the "disk offline" question. It seems that it was mentionned several
times on the mailing list.
Here are few other ideas I had during the weekend.
- My problem was due to the fact I did a ./configure --with-user=14
going with userID instead of user name. Maybe it could be clearly
mentionned it should be the name and not the ID.
- It appears that the estimation of the size is done with
euid=ruid=amanda while the effective back-up (runtar) is done with
ruid=amanda and euid=root. It would give a more accurate estimate if
it was run with euid=root I think.
- Apparently amcheck do not perform as deep verification as some cases
can arise when amcheck will report OK while the dump will fail. The
above case was one of it.
- Runing amanda 2.4.2p2, with gnutar, there is no more problem with
disk access permission: I configured/install amanda, as user/group
amanda, did not modify anything on the disk, did not set up amanda
in the goup orperator, wheel or whatever, and it runs smoothly.
It is a great tool, thanks,
Olivier
