Re: [Bug-tar] wishlist: transparent compression on file- and not archive level

[Christian Hammers]

Hello

On 2006-07-26 Phillip Susi wrote:
> If you bunzip each of the individual recovery files generated by 
> bzip2recover, do they each decompress to exactly 921600 bytes?

Just for the record: Further tests revealed that tar is ignoring any
--blocking-factor or --record-size options and always begins a new record at
a multiple of 512 bytes. But this should be fine as it is always a factor
of bzip2's block size.

Regarding your question, no they decompress to sizes that always
vary around 100kb for "bzip2 -1" resp. 900kb for "bzip2 -9":

        -rw------- 1 ch ch 121904 2006-07-26 23:30 ./rec00001test.tar
        -rw------- 1 ch ch 104577 2006-07-26 23:30 ./rec00002test.tar
        -rw------- 1 ch ch  99981 2006-07-26 23:30 ./rec00003test.tar
        -rw------- 1 ch ch 101181 2006-07-26 23:30 ./rec00004test.tar
        -rw------- 1 ch ch  99938 2006-07-26 23:30 ./rec00005test.tar
        -rw------- 1 ch ch  99974 2006-07-26 23:30 ./rec00006test.tar

The tar header are therefore not at offsets which are 512 byte multiples:

        $ ../find_tar_headers.pl recovered_2nd_half.tar
        header found at offset 4071084 = 3e1eac hex
        header found at offset 4086956 = 3e5cac hex
        header found at offset 4099244 = 3e8cac hex
        ...

The best would IMHO to give tar a "--thorough-header-scan" option which goes
byte for byte, may it take hours, to find a header. Or just refer in the
manpage to cpio as better tar extractor for such cases *g*

bye,

-christian-



> Christian Hammers wrote:
> > So..
> > Alternative 1 "creating a .tar.bz2 that recovers to correct .tar files":
> >   bzip2 by default and in this case explicitly specified is 900kb (Option
> >   "-9"). So I created my test tar file with
> > "--blocking-factor=1800" (and with 900, did not make any difference).
> > 
> >   Still, after I run bzip2recover, the first recovered block after the
> >   corrupted one starts with 158065 junk bytes.
> > 
> > Alternative 2 "recovering a .tar.bz2 and let tar extract what's left":
> >   That does not work, too, as is unable to skip those 158kb byte of
> >   junk and then continue to recover the rest of the 250MB of data.
> > 
> >   If, for performance reasons searching beyond the first e.g. 1kb is not
> >   done there should be a corresponding option.
> > 
> >   To my surprising tar's direct competitor cpio was able to restore the
> >   broken *tar* file e.g. did exactly what I wanted :-)
> >   "cpio -F part2.tar -i --no-absolute-filenames --make-directories -v"
> > 
> > Any more ideas what should be the "documented" way of dealing with
> > compressed tar archives?
> > 
> > bye,
> > 
>