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

[Phillip Susi]

My guess would be that bzip2 and tar are using different block sizes, 
and when tar attempts to seek to the next block header, it only looks 
for the magic number on an even block boundary.  IIRC, tar uses a 5120 
byte block size by default.  Look at the exact block size that bzip2 is 
using and make sure tar uses a block size that evenly divides into the 
bzip2 block size.

Christian Hammers wrote:
> This would be enough, theoretically. In practice though, the experiment
> failed:
>  - tar czf test.tar.bz2 /home/ch/doc/pics/    # 1200 files with 160MB
>  - hexedit test.tar.bz2  # insert 8 zeroes at about 15%
>  - bzip2recover test.tar.bz2 # 192 rec00XXX.tar.bz files created
>  - bunzip2 rec*.bz2          
>  - mv rec00019.tar.bz bad00019.tar.bz
>  - bunzip2 rec*.bz2                    # uncompress the remaining
>  - cat rec*.tar > recovered.tar
>  - tar xvvf recovered.tar
>       ...
>      -rw-r--r-- root/ch     1007332 2006-05-29 20:54  \
>          home/ch/doc/pics/Freunde/Anna (Lousberg) 2.jpg 
>      tar: Skipping to next header 
>      tar: Error exit delayed from previous errors
>
> Although only 35 files in 17MB were restored, tar aborts.
> As told with "string |grep -c home/ch/doc" there should be
> 1103 files in 166MB in recovered.tar.
>
> So what am I doing wrong here?