[Bug-tar] Re: Can't extract - get "Archive contains obsolescent base-64 headers"

[Alexis Huxley]

> That "Archive contains obsolescent base-64 headers" message that you
> got was bogus, though.  I installed the following patch.  Thanks
> for reporting the problem.

No problem, but going back to my unrestorable DAT ... :-)

... I used 'split -b 1024' and hexdump to try to examine the tar file. The 
first 1024 bytes are:

00000000  2e 2f 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |./..............|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000060  00 00 00 00 30 30 34 30  37 30 30 00 30 30 30 31  |....0040700.0001|
00000070  37 35 30 00 30 30 30 31  37 35 30 00 30 30 30 30  |750.0001750.0000|
00000080  30 30 30 30 30 30 30 00  30 37 37 31 33 35 33 34  |0000000.07713534|
00000090  33 33 37 00 30 31 30 35  35 35 00 20 35 00 00 00  |337.010555. 5...|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  00 75 73 74 61 72 20 20  00 61 6c 65 78 69 73 00  |.ustar  .alexis.|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 61 6c 65 78 69 73 00  |.........alexis.|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  2e 23 61 60 28 04 00 00  00 00 00 00 00 00 00 00  |.#a`(...........|
00000210  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000260  00 00 00 00 30 30 34 30  37 30 30 00 30 30 30 31  |....0040700.0001|
00000270  37 35 30 00 30 30 30 31  37 35 30 00 30 30 30 30  |750.0001750.0000|
00000280  30 30 30 30 30 30 30 00  30 37 37 31 33 35 33 34  |0000000.07713534|
00000290  31 37 36 00 30 31 31 33  35 35 00 20 35 00 00 00  |176.011355. 5...|
000002a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000300  00 75 73 74 61 72 20 20  00 61 6c 65 78 69 73 00  |.ustar  .alexis.|
00000310  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000320  00 00 00 00 00 00 00 00  00 61 6c 65 78 69 73 00  |.........alexis.|
00000330  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

I'm confused here. The first item in the tar is a directory ("./"), so
there  should be no datablocks following it. But looking at bytes 512
(0x200) onwards,  it doesn't look like another header block; there is no
pathname at 512 to  512+100 (just ".#a`(") although ... there *is* a 
permission and the 'ustar' thing etc.

Okay, so then I thought that perhaps this second 'ustar' was just some
junk left in an uncleaned (and not required to be cleaned) buffer: I was
guessing that the block size was actually 1024 bytes.

So then what comes after *this* 1024 bytes should be the next header
block, right? What follows is:

00000000  2e 2f 73 65 78 2f 44 44  35 38 2e 4d 50 47 00 00  |./doc/DD58.DOC..|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000060  00 00 00 00 30 31 30 30  36 30 30 00 30 30 30 31  |....0100600.0001|
00000070  37 35 30 00 30 30 30 31  37 35 30 00 30 30 30 30  |750.0001750.0000|
00000080  35 31 37 37 36 34 36 00  30 37 31 33 33 36 32 30  |5177646.07133620|
00000090  32 35 32 00 30 31 32 34  30 32 00 20 30 00 00 00  |252.012402. 0...|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  00 71 70 60 60 20 20 00  00 60 64 60 68 61 00 00  |.qp``  ..`d`ha..|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 60 64 60 68 61 00 00  |.........`d`ha..|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  00 00 01 ba 21 00 01 00  1f 80 07 81 00 00 01 bb  |....!...........|
00000210  00 0c 80 07 81 07 21 ff  c0 c0 20 e0 e0 2e 00 00  |......!... .....|
00000220  01 be 07 dc ff ff ff ff  ff ff ff ff ff ff ff 0f  |................|
00000230  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

Okay, that looks fine. So now I'm thinking, yes, the block size *is*
1024 bytes.  So I extract the size of DD58.DOC out of the header
(1376166 bytes) divide that by 1024 and ceil() that to get the number of
datablocks that follow, skip that many and read the next header block
that comes after that:

00000000  2e 2f 73 65 78 2f 77 69  66 65 79 30 30 30 30 30  |./doc/someextrem|
00000010  31 20 28 74 68 65 20 62  65 73 74 20 6f 66 20 77  |lylongfilenameth|
00000020  69 66 65 79 20 2d 20 6f  76 65 72 20 37 20 6d 69  |atyoucaneasilywo|
00000030  6e 75 74 65 73 20 6f 66  20 62 6c 6f 77 6a 6f 62  |rkoutbylookingat|
00000040  2c 20 68 61 6e 64 6a 6f  62 2c 20 66 61 63 69 61  |thehexvaluesonth|
00000050  6c 2c 20 63 75 6d 73 68  6f 74 20 61 63 74 69 6f  |theleftbutwhysho|
00000060  6e 20 2d 20 70 6f 72 6e  6f 67 72 61 70 68 79 20  |uldyoudothatrigh|
00000070  2d 20 73 65 78 20 2d 20  68 61 72 64 63 6f 72 65  |tunlessyouarecur|
00000080  20 78 78 78 29 2e 6d 70  67 00 00 00 00 00 00 00  |ious.html.......|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  2e 23 61 60 28 27 61 60  64 61 30 30 30 30 30 30  |.#a`('a`da000000|
00000210  20 20 20 60 60 20 20 60  61 70 20 20 66 20 20 61  |   ``  `ap  f  a|
00000220  60 64 61 20 20 20 20 66  64 60 20 20 20 20 69 68  |`da    fd`    ih|
00000230  64 74 64 61 20 20 66 20  20 60 6c 67 62 6a 62 20  |dtda  f  `lgbjb |
00000240  20 20 60 60 64 60 6a 62  20 20 20 60 61 61 61 60  |  ``d`jb   `aaa`|
00000250  2c 20 20 61 65 61 60 68  64 20 20 61 60 60 69 6e  |,  aea`hd  a``in|
00000260  24 20 00 00 30 30 30 30  30 30 00 00 30 30 30 31  |$ ..000000..0001|
00000270  35 30 00 00 30 30 30 31  35 34 00 00 30 30 30 32  |50..000154..0002|
00000280  34 30 30 37 32 31 10 00  30 35 35 34 34 34 30 34  |400721..05544404|
00000290  30 31 37 00 30 31 31 31  35 35 00 20 30 00 00 00  |017.011155. 0...|
000002a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000300  00 75 73 74 61 72 20 20  00 61 6c 65 78 69 73 00  |.ustar  .alexis.|
00000310  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000320  00 00 00 00 00 00 00 00  00 61 6c 65 78 69 73 00  |.........alexis.|
00000330  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

And here the filename really does extend well beyond the 100 bytes in the
tar file and the file really was named with such a long name when I created
the tar file.

I wrote a small perl script to unpack the headers and do a CRC-less extraction,
and I believe I can do it for the first file with the short name, but now
here I'm stuck. 

Is the missing size the cause of why I got my original error message? Or is
the size and the other header fields just at a different offset? Is this
new offset computable? 

And if this long filename is the source of the problem, then why did the
orginal 'tar tvf' command choke immediately after reporting the "./" info,
and not after "./doc/DD58.doc" - which it could have successfully reported
(*both* being prior to the very long file name)?

If I can get the length, then I can improve a perl script I've started to
extract the data.

Thanks for continued assistance!

Alexis