On Nov 16, 2000, John Goerzen <[EMAIL PROTECTED]> wrote:
> The compressed representation of each block is delimited by a
> 48-bit pattern, which makes it possible to find the block
> boundaries with reasonable certainty. Each block also carries
> its own 32-bit CRC, so damaged blocks can be distinguished from
> undamaged ones.
Ok, so you lose a block, bzip2 skips it and proceeds to decompress the
succeeding block. I can believe GNU tar would be able to recover from
the loss of the intermediate block, if you're lucky enough, but I'm
not sure DUMP would. So beware.
> Are there any plans to support this? I suppose I could just go into
> the code with sed and s/gzip/bzip2/ but I'd prefer to do it more
> elegantly if possible :-)
Some people have tried bzip2 before. Invariably, they'd come back and
agree it was indeed way too slow to be worth the extra compression of
back ups.
Which is not to say I despise bzip2. On the contrary: I use it often,
but for compressing files, not whole backups that I want to get
finished before next day's backup starts :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
