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?
_______________________________________________
Bug-tar mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-tar
