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. _______________________________________________ Bug-tar mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-tar
