backup with compressed cpio files ?

[Robert Breckinridge Beatie]

In article <872 at deimos.cis.ksu.edu>, tar at ksuvax1.cis.ksu.edu (Tim Ramsey) writes:
> In article <9100001 at netmuc> bothe at netmuc.UUCP writes:
> 
> >what i suggest is to save my files with:
> >find . -print | compress | cpio -oacB >/dev/rmt0
> 
> 1) You can't compress the output from find and pipe that into cpio.  Try:
>       find . -print | compress | cpio -oac > /dev/rmt0

How is this different?  You're still passing compressed find output to
cpio.  Don't you (and bothe at netmuc) mean:
		find . -print | cpio -oac | compress > /dev/rmt0
?
> 
> 2) If you get a bad spot on the tape later you won't (never say never :-)
>    be able to recover anything beyond the bad spot.  This is a tradeoff
>    when you use compress.

Isn't this just as much a problem with cpio?  It doesn't seem to be too
robust, so even if the output weren't compressed, cpio would just complain:
	"Out of sync: better luck next time"
or some similarly irritating message.  It seems you'd have to unpack the
file by hand.

And as long as we're unpacking the file by hand, would it be possible to
look for the "reset" marks that compress leaves in its output periodically
and then pick up from that point?  I thought that compress, when its code
tables fill up and when it figures that its compression effeciency is
decreasing that it wrote a "reset" symbol and then cleared its code tables
and effectively started over from scratch.

So, would it be possible to take the data on the tape after the reset
symbol, prepend a compress header to that data, and hand that stream
to uncompress and get back at least part of what you had on the tape
after the bad spot?

Of course, I'm not that familiar with the workings of compress so I
could be way off base here.

-- 
Breck Beatie	    				(408)748-8649
{uunet,ames!coherent}!aimt!breck  OR  breck at aimt.uu.net
"Sloppy as hell Little Father.  You've embarassed me no end."