2

I have a corrupt tarball on my hands. My first attempt at recovery went like this:

$ tar --ignore-failed-read --ignore-command-error -xf tarball.tar
tar: Skipping to next header tar: Archive contains ‘180738 0’ where numeric mode_t value expected
tar: Archive contains ‘0.445647 -9.’ where numeric time_t value expected
tar: Archive contains ‘.259273 ’ where numeric uid_t value expected
tar: Archive contains obsolescent base-64 headers
tar: Archive contains ‘-0.94874’ where numeric gid_t value expected
tar: text from a text file is here: implausibly old time stamp 1969-12-31 18:59:59
tar: more text file contents are here: Unknown file type 'p', extracted as normal file
tar: Skipping to next header
tar: Skipping to next header
tar: Exiting with failure status due to previous errors

This didn't extract much from the tarball before erroring out. The exit status is 2 which the tar man page says is a fatal error.

The documentation for "gzip Recovery Toolkit" suggested this:

cpio -F tarball.tar -i -v

This extracted 1.2G of a 1.8G tarball, which is pretty good. It stops with a bunch of garbage entered after the terminal prompt -- it isn't printed to the screen, it's as if I had typed it and didn't hit return yet.

Is there a way to do any better? Is there a way to try and "jump over the bad chunks" of the tarball?

With --ignore-zeros tar seems to be reading through the entire tar file.

tar -R --ignore-failed-read --ignore-command-error --ignore-zeros -xvf tarball.tar
[...]
block 3670356: ** Block of NULs **
block 3670357: ** Block of NULs **
block 3670358: ** Block of NULs **
block 3670359: ** End of File **
tar: Exiting with failure status due to previous errors

There are a lot of Block of NULs errors so it looks like the contents might be irretrievable.

2

You are not using tar but gtar and the error message:

tar: Archive contains obsolescent base-64 headers

is related to a well known bug in gtar that is reported repeatedly since more than 20 years. There have been source changes in the past that made this problem less probable but these changes did not yet really fix the related problem in gtar.

If you like to check your archive, you could use tartest from the starpackage and you could try to use star to extract the archive and star -i in case that star reports errors.

  • Interesting! I'll have to try this. Is the bug something that can be explained briefly? Is there something fundamental about how gtar works that prevents it from being fixed? – Praxeolitic Sep 5 '15 at 0:15
  • The problem with gtar is that there is no common routine to read the data structures but everything is done separately even though there should only be two (one for reading the data structures and one for creating them). – schily Sep 5 '15 at 9:42
  • The social background is: Star is maintained by me since 1982. Gtar started as PD-TAR/SUG-TAR from John Gilmore (a Sun employee) in late 1986 and it was taken by Stallman in 1989. In the early 1990s, the maintained changed frequently and in that time (1993) I first reported the problem. – schily Sep 5 '15 at 9:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.