Jean-Francois Malouin wrote:

* Jean-Louis Martineau <martineau AT zmanda DOT com> [20081104 13:46]:

Jean-Francois Malouin wrote:

Is this a new feature? I've done restore as root in the past I'm sure
and never seen this before. Have been living blind all this time? :)
So I guess I was lucky enough to do the amfetchdump in a dir owned by
amanda and then it could recreate the dir structure and file
ownerships...

Maybe you were using amrestore? It doesn't need amanda privilege.

I've used both for testing purposes before.
I've just finished a new restore test on a new piece of hardware:

# su amanda -c "/opt/amanda/sbin/amfetchdump -b 2048k -p -d
tape:/dev/nst0 top gustav /raid/ipl 20081104 | tar -xpGf -"

# su amanda -c "/opt/amanda/sbin/amfetchdump -b 2048k -p -d tape:/dev/nst0 top 
gustav /raid/ipl 20081104" | tar -xpGf -

Look where I put the ".

completes ok, looks good, the dle was successfully restored but tar
didn't restore the original ownerships of the dirs and files, they all
belong to user 'amanda' and group 'disk', its primary group, as I was
suspicious it would do in the first place, but I wanted to be 100%
sure before posting.

# tar --version
tar (GNU tar) 1.16

I don't see this on a another system, running the same amanda version,
2.5.2p1, but from a much earlier configured and compiled tarball

Proof is in the pudding. From a debug amandad:

amandad: time 0.016: build: VERSION="Amanda-2.5.2p1"
amandad: time 0.016:        BUILT_DATE="Fri Jul 6 12:27:48 EDT 2007"
amandad: time 0.016:        BUILT_MACH="IRIX64 wart 6.5 01062343 IP27"

yorick 117# /opt/amanda/amanda1/sbin/amfetchdump -p -d
/hw/tape/tps21d1nrnsv stk_80-conf1 yorick /data/speechprod/speechprod2
20081030 | /usr/freeware/bin/tar -xpGf -
1 tape(s) needed for restoration
The following tapes are needed: 000038
Press enter when ready

Scanning 000038 (slot 1)

and the restore completes ok. That's with tar (GNU tar) 1.13.25.

So that leads me to believe that it's either something that has been
backported in the tarball for 2.5.2p1 since then or is it a problem
with tar 1.16 on a Debian Etch machine?

thanks,
jf

Jean-Louis