Conference cookie::archive_backup

can you try creating a non-staged catalog and modify the save
request to use the new catalog, then run the save request.

Thanks
Jim

    
    We need some clarification :
    
    We know that report save_log/full command is printing some bogus data,
    and we are looking into it. The number of the archived object field
    does not contain corect information.
    
    For the successful unix saves which has 2 data items specified (for the 
    log pointed in .0), are you able to perform catalog lookup or restore
    of the files saved?  Can you lookup files from the 1st save successfully?
    (/user/users/knol/test/somefilename)  Can you lookup from the 2nd save
    successfully? (/usr/users/knol/otherfilename)
    
    If the lookup is successful, the issue is report save_log command is
    broken.
    
    If the lookup is not successful, we have catalog update problem (and
    report save_log problem).
    
    Can you clarify?
    Masami
                           

    I can't restore any files from the first because the catalog doesn't
    contain a name of the saveset or volume. I can however restore the
    second saveset without a problem.

    
    Jan,
    
    Ignore the output of report save_log/full.  The number of archived
    object field has bogus numbers as far as I can tell.  If it indicates
    0, it does not mean it is *not* cataloged.  I tested here myself and
    was able to successfully lookup from the saves that says "number of
    archive objects = 0" in report save_log/full.
    
    Report save_log/full problem is QARed and we'll get it fixed.
    
    If you cannot restore/lookup from the first save object, will you
    post the show restore/full output of the failed restore request?
    Also, posting the failed restore log will help.  
    
    We are trying to get the problem reproduced here.
    
    Masami

Hi Jan,
In addition to Masami's questions in the prior reply, I have a few more.


I tried creating a save with 2 unix objects.  The first was
/usr/users/lewis/a.a          and the second specified 
/usr/users/lewis/

the save ran successfully.  The report save_log showed what you are seeing.
Only one entry in the save_log contains a number for number of archived objects.

However, if I do an 
abs lookup "/usr/users/lewis/a.a"  it finds both entries (because the directory
    entry will also save a.a a second time.
  *** (Does this work for you?)
abs lookup "/usr/users/lewis/b.b" does find 1 entry, from the dir save.

I then tried to restore both a.a and b.b in a single restore.  That also worked
fine.
  ***did you actually try a restore?

In the log of the save operation you provided in .0, I notice the message
indicating the template file has been changed
 "agent information has been altered"
 "error checksumming agent information"
Do you know why you are seeing this?  (I believe we did have a problem with
the gtar template in v2.0 that caused dates east of GMT to return invalid
date errors.  Did you modify the template to correct this, or for something
else?)
Can you provide your template? (You can put them here, or send them to me.)
  (I assume you are running v2.0 of ABS)

Thanks
Jim

    re .9
    
    sorry for the late answer, but yes you are right I can do a selective
    restore from both the saves 
    My mistake was the filename , is used a wildcard which is not supported
    So the only issue left is the report sav_log output is wrong
    
    regards,
    jan