ADSM-L

Re: previous append from Mitch

1994-05-13 11:40:53
Subject: Re: previous append from Mitch
From: Bill Colwell <BColwell AT CCLINK.DRAPER DOT COM>
Date: Fri, 13 May 1994 15:40:53 GMT
In <1994May13.141729.19346 AT draper DOT com>, HOOBLER AT gdlvm7.vnet.ibm DOT 
com (Del
 Hoobler) writes:
>|| If I restore by subdirectory path which includes a file called foo while:
>||
>|| viewing active AND inactive
>|| retrieve to any location (I don't think it matters)
>|| REPLACE THE EXISTING FILE
>||
>|| What happens?
>||
>|| Specifically, does it restore the latest version?
>|| Does it restore all versions and keep overwriting or is it smart enough
>|| to only restore one time?
>
>
>Mitch.  ADSM will detect this situation and only restore the LATEST
>version of the file whether it be active or inactive.  Inactive in
>the case where there is no active version.
>
>ADSM will only try restoring ONE file, not one over-top another.
>The code sorts the files on name and date, then eliminates duplicates
>from the list of files to restore.
>
>Del

 A Sun client user recently had a lot of trouble doing a restore which
would have been a lot easier if restore-by-subdir-path were improved
to handle inactives.  The user wanted to restore a database of some
sort and many associated files in a directory and numerous
subdirectories.  Restore-by-filespec doesn't show the subdirectories,
and restore-by-subdir-path handles the subdirectories but doesn't
allow selection.  That left restore-by-tree, and displaying each
directory, sorting, and selecting which see did.  When the whole
restore list was built, the client promptly core dumped and quit!
(IP20127 may fix this and we are testing it).

 Del says the restore-by-subdir-path sorts by name and date when the
Inactives are displayed.  Could it be enhanced to accept a 'not later
than date' parameter to throw out the more recent versions and then
restore the best available version?  If enough inactive versions are
kept, this would be an interim 'point in time' facility. It would be
just what was needed in this case.  (I am addresing this to the GUI
client.)

Bill Colwell
C. S. Draper Lab
Email: BColwell AT draper DOT com
Voice: 617-258-1550
<Prev in Thread] Current Thread [Next in Thread>