get/build a copy of 1.13.25

I got:

tar --version

tar (GNU tar) 1.13

Don't know where to find the .25 ?...

When I tried to restore the link, it failed:
amrecover> add dbsp
Added /dbsp
amrecover> extract dbsp
Extracting files using tape drive file:/saves/monthly on host reddog.
The following tapes are needed: monthly4
Restoring files into directory /home
Continue [?/Y/n]? y
Extracting files using tape drive file:/saves/monthly on host reddog.
Load tape monthly4 now
Continue [?/Y/n/s/t]?
EOF, check amidxtaped.<timestamp>.debug file on reddog.
amrecover: short block 0 bytes
UNKNOWN file
amrecover: Can't read file header
extract_list - child returned non-zero status: 1

- Jerome

To: <amanda-users AT amanda DOT org>
Sent: Wednesday, September 28, 2005 10:26 AM
Subject: Re: Symbolic links

On Wed, Sep 28, 2005 at 09:28:54AM -0700, Jerome Pioux wrote:

Frank, Jon

>...
>or possibly an OS that refuses to create a link to a non-existent target
>...

Well, you may have pointed out the real problem above.

The way the restore went, filesystems with links may have been restored
first and pointing, at the time, to non exiting targets (btw: the os was

AIX53). To make the matter worse, I can see now that most of the links are

also

links to other locations. Now I bet that the explanation above is the right

one !

I will run a few tests with amanda to verify the theory and base on the
results,

will probably be doing some changes in the order we restore things from now

on...

I've not run across a system that did not allow symlinks to be created
to non-existing entries.  So I peeked at IBM's website for aix53 docs.
According to the ln(1) manpage:

  "The source file does not need to exist
   before creating the symbolic link."

Looking at lower levels, at the link(3) and symlink(3) manpages,
I see nothing contrary to that statement.

I'd be more inclined to suspect problems with gnutar.  As one emperical

test, get/build a copy of 1.13.25 rather than 1.15.1. See if that version,

which many amanda sites use, acts differently.

--
Jon H. LaBadie                  jon AT jgcomp DOT com
JG Computing
4455 Province Line Road        (609) 252-0159

Princeton, NJ 08540-4322 (609) 683-7220 (fax)

amidxtaped.20050928115236.debug
Description: Binary data