[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-tar] Re: Can't extract - get "Archive contains obsolescent base-64
From: |
Alexis Huxley |
Subject: |
[Bug-tar] Re: Can't extract - get "Archive contains obsolescent base-64 headers" |
Date: |
Fri, 4 Feb 2005 11:37:17 +0100 |
User-agent: |
Mutt/1.4.2i |
> 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