On Sat, Mar 04, 2006 at 12:14:21PM +0000, Tony van der Hoff wrote:
> Gene Heskett <gene.heskett AT verizon DOT net> wrote in message
> <200602281004.52325.gene.heskett AT verizon DOT net>
> 
> > On Tuesday 28 February 2006 09:25, Tony van der Hoff wrote:
> > > Gene Heskett <gene.heskett AT verizon DOT net> wrote in message
> > > <200602271737.46076.gene.heskett AT verizon DOT net>
> > >
> > > [snip]
> > >
> > > > And at this point, I am lost.  I'm not familiar with the syntax you
> > > > are using for the excludes specification, particularly the "*" of that
> > > > spec as you are using it.  No idea if thats something new or what.
> > >
> > > Thanks, Jon and Gene :)
> > >
> > > I'll make those changes to the config files as you suggest, I might as
> > > well get it right. I feel like it's grasping at staws, though; this
> > > config has been working for 3 years :(
> 
> OK, I've been doing some more research. I didn't think I'd just dreamt up
> that * syntax :)
> 
> As I understand it, Amanda passes the exclude file name on to GNU-tar (man
> amanda):
> exclude [ list|file ][[optional][ append ][  string ]+]
>         Default: file. There are two exclude lists, exclude file and ex-
>         clude  list. With exclude file , the string is a GNU-tar exclude
>         expression. With exclude list , the string is a file name on the
>         client containing GNU-tar exclude expressions.

One minor clarification, expressed in this last line.

>         All  exclude expressions are concatenated in one file and passed
>         to GNU-tar as an --exclude-from argument.

It is not the file name you provide, but a temporary one created from
all the appended exclude args and list file contents.  I.e. a "super"
exclude file is created for the run.

> Now GNU-tar accepts wildcards in the exclude list, unless the switch
> --no-wildcards is specified. Amanda's not doing that. 
> >From man tar:
> -X, --exclude-from=FILE
>         exclude patterns listed in FILE
> note _patterns_
> 

Isn't there also something on the page about gnutar having to be built
with the regex options for the patterns to be full featured?

> So, I've fixed those disk lists, and did another amdump, followed by an
> amverify. Same result: amverify hangs/crashes seemingly at the end of tape,
> without any meaningful report. So I think the disk list problems are a bit
> of a red herring.

I believe I said something similar when I commented about the disklist.

> I then did some dd restores for all the DLEs on the tape, and it turns out
> that the very first image is corrupt, causing GNU tar (1.15.1) to abort with
> an error. However, amverify doesn't spot this, and happily extracts
> everything from the tape, piping it into thin air, until it reaches EoT,
> after which it simply hange.
> 
> I've been trying, with little success so far, to figure out why this
> particular image is corrupt; it is absolutely repeatable on successive
> amdump runs, but the disk directory seems OK. Can anyone point me at the
> code that creates the image, please.
> 

Clarification please.  Does it always seem corrupted on the first taped image?
Is that the only corrupted image.  Is that first image always the same DLE.

Reason I ask is to check if a manual dump of a DLE that consistantly corrupts
could be used to confirm that it can be dumped successfully outside of amanda.
Find the exact command line and try running it.  Don't forget to build an
exclude file. :)

BTW amverify may not be doing all that much.  The dump programs are specific
to the clients and may not be available on the tapehost.  In that case all
amverify can do is see that the tape is readable.

-- 
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)