SUN's ufsdump has an option
a <archive_file>
which produces a table of contents file where ever
you specify. This can be interogated with
ufsrestore -ia <archive-file>
instead of having to load a tape and interogate the
table at the the beginning of the dump on the tape.
We find this incredibly useful in locating which
tape to restore from.
Thanks.
Garry Ferguson
Logged In: YES
user_id=5513
Can you send me an example of this generated archive file so
I can analyse its contents ?
As for its usage, am I correct assuming that with such an
archive file you can do:
do not put any tape into the drive
$ restore -i -a -f /dev/tape
walk into directories, select files to extract, ex
restore prompts directly for the good tape (maybe not 1)
So it's possible for restore to not read at any moment the
tape no. 1...
Stelian.
eg of SUN's ufsdump on-disk archive.
Logged In: YES
user_id=431397
Stelian, I attach an example archive file created by SUN's
ufsdump:
$ufsdump 0af /tmp/filesystem1.archive /dev/tape /filesystem1
/filesystem1 contains just 5 directories called dira .. dire
with a few files in each called file1, file2 etc. There are
also a few sub-directories called, eg, dira-sub1.
SUN's ufsrestore could use it with:
$ufsrestore -ia filesystem1.archive
you can walk through the structure and "add" as required.
When you type "extract" you are prompted to mount a tape.
The structure you walk through is identical to that you
would see with:
$ufsrestore -if /dev/tape
Hope that helps. Regards, Garry
Logged In: YES
user_id=5513
Thanks for the file Garry.
However, even with this file, I fail to see how this file
could be used to determine, given some inodes, the tape
number which should be prompted for.
Could you please do the same dump as before, but limit its
volume length with a -B <something> option, in order to
create at least two volumes.
Then, when you 'ufsrestore -ia filesystem.archive', select
one of the inodes which is on the _second_ volume (take the
inode having the bigest inode # for example), and please
confirm that ufsrestore prompts you to mount the
_second volume_ directly.
If it works this way, please attach the new archive file...
Stelian.
Logged In: YES
user_id=431397
Stelian, Yes "ufsrestore -ia archive-file" prompted for
volume 1 or 2, whichever the "added" file was on.
I've tarred together the ufsdump and ufsrestore session
outputs with the requested new archive file.
Regards, Garry
Logged In: YES
user_id=5513
Ok Garry, got the new archive file and found where the
information is stored. I implemented this feature in
dump/restore, it should work exactly the same way (except
that the option is toggled with -A, because -a was already
taken).
Could you please test the prerelease version available here:
http://dump.sourceforge.net/ftp/dump-0.4b27-pre1.tar.gz
and report your success/failure with it ?
Stelian.
Logged In: YES
user_id=431397
Stelian,
Tried a quick usage of dump/restore-0.4b27-pre1 and the -A
looks to work just fine. What a star you are! How come you
have time to do these things so quickly?
Thanks and regards, Garry
Logged In: YES
user_id=5513
:-)
This feature was on my todo list for a long time.
It wasn't so difficult to implement, once you understand how
to do it...
To be complete, I must also say that you had just found a
hole in my schedule last week :-)
Stelian.
Logged In: YES
user_id=5513
Dump 0.4b27 released, so I'm closing this feature request as
resolved.
Enjoy.
Stelian.