[Bug-tar] Verify failures and "obsolescent base-64 headers"

[Andreas Grosche]

Comparing some 20 gigabytes of backups to their original file systems I was
surprised to see tar-1.3.25 (which had created them) report errors such as:

# tar --diff --totals --file a_backup.tar

./user/.spamassassin/bayes_toks.new: Could only read 0 of 28160 bytes
./user/.spamassassin/bayes_toks.new: Could only read 0 of 28160 bytes
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
./user/.spamassassin/bayes_seen: Could only read 0 of 28160 bytes
./user/.spamassassin/bayes_seen: Could only read 0 of 28160 bytes
tar: Skipping to next header
Kilobytes Out 1652000
tar: Error exit delayed from previous errors

... which "mysteriously" and gradually seemed to disappear when checking the
individual files in small groups or one by one (log excerpts for convenience):

# tar --diff --file a_backup.tar ./user/.spamassassin/bayes_toks.new 
./user/.spamassassin/bayes_seen ./user/.spamassassin/bayes.lock

./user/.spamassassin/bayes_toks.new
./user/.spamassassin/bayes_seen
./user/.spamassassin/bayes_seen: Contents differ
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
./user/.spamassassin/bayes.lock

# tar --diff --file a_backup.tar ./user/.spamassassin/bayes_seen 
./user/.spamassassin/bayes.lock

./user/.spamassassin/bayes_seen
./user/.spamassassin/bayes.lock

In another archive, there were similar effects additionally even involving
error messages about wrong block number references (may try and reproduce these
with logs if still required, cf. remainder of this message).

Media/driver errors, unlikely to go undetected anyway as the DDS3 drive uses
read-after-write, have been excluded by running the above commands as well as
md5sum on the tapes and hard disk copies of identical tarballs, and reproducing
these symptoms there as well.

The effects may be related to an earlier (apparently unresolved) discussion in
http://groups.google.de/group/comp.unix.solaris/browse_thread/thread/d069cb790c5710a8/ba69a978ed93d98a
- and no errors are detected when using tar-1.15.* -diff on the same archives.

This seems to indicate some severe bug in tar-1.3.25, which is still widely
in use - though I couldn't find whether there has been a discussion to pinpoint
and explicitly fix the exact cause for these problems at some point in time.

As discussed in the above Solaris thread, it is rather difficult to build a
test case reproducing this problem with "dummy" data, while it seems to have
all the hallmarks of a hardware defect or kernel/driver issue at first sight,
but in fact it is not caused by any of these. (Indeed the above could even be
reproduced on ancient linux-2.4.20.SuSE [8.2] with an ISA[!] AHA-1542 that has
been running reliably for ages... Even there, e.g. simply using bin/tar from
ftp://ftp.suse.com/pub/suse/i386/9.3/suse/i586/tar-1.15.1-5.i586.rpm did the
trick, on archives previously created [and considered corrupt by] tar-1.3.25!)

So is there a risk of running into similar troubles with later versions of tar,
or starting from which version, if any, can this issue be considered fixed?

Thanks in advance for your replies.