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

[Jean Delvare]

Hi Alexis,

> > So I start wondering if the strange second entry ".#a`(" (2e 23 61 60
> > 28 04) couldn't in fact be that missing directory, "./doc/". That
> > would explain this additional 512-byte block. And the string length
> > matches...
> >
> > Or course I might as well be completely wrong, but you could try editing
> > the dump file and write "./doc/" at 0x200, and see what happens. IMHO
> > that's worth the try.
>
> Wow ... thanks, that helped somewhat:
>
>dione$ tar tvf tape.dump.X
>drwx------ alexis/alexis     0 2003-08-04 21:49:51 ./
>drwx------ alexis/alexis     0 2003-08-04 21:48:14 ./doc/
>tar: Skipping to next header
>tar: Archive contains obsolescent base-64 headers
>tar: Error exit delayed from previous errors
>dione$

Hey, I'm really glad it worked. Of course it doesn't help by itself,
one more empty directory will not make you any happier. However, it
might improve our unserstanding of how your data has been corrupted -
since I believe we now all agree that data corruption has occured.

> Before it only produced the "./" line, so this is an improvement. Okay, but
> then this confirms that the record length is 512 bytes, and not 1024; I'll
> try playing with my perl extraction script some more, but I'll still
> confused about how I get the size of the later file.

Agreed with the 512 bytes size, that's the standard as I knew it too.
However my knowledge about the tar headers is somewhat limited so I
cannot tell much more, in particular I have no idea how file size are
computer and stored. The good thing here is that you have the GNU tar
sources to took at ;)

As a side note, I would like to mention that I think that these two lines:
  tar: Skipping to next header
  tar: Archive contains obsolescent base-64 headers
have *different* causes. I mean it would really be two different errors
at two different locations in the stream, the first non-fatal, the
second fatal. Again, not sure how it helps, but...

OK, since my first suggestion worked, I'm on my way to a second one.
Take a look at the block starting at 0x500. Supposedly this is format
and owner information for the first non-directory file in the archive,
similar to 0x100 and 0x300. But here the header is obviously corrupted,
exactly like the file name was at 0x200 before you fixed it. So I would
invite you to overwrite 0x500-0x53f with the block from 0x100-0x13f (or
0x300-0x33f, which is the same as far as I can see). Maybe that'll let
you go one step further again, maybe not.

That said, I don't want to look pessimist, but what I see there starts
looking like more or less random corruption, whatever the cause was, so
there is no reason it would have affected headers and not data itself.
We might fix the headers with sufficient patience and work, but we
probably won't be able to fix the file contents.

--
Jean Delvare