This problem hasn't been fixed yet. If you think you can help us to find a workable solution to the problem, or you have an opinion on the possible solutions presented, please contribute!
-- Steven Andreason

On June 2, 2005, it was confirmed that an unknown TAR file creator (not any version of GNU tar, as far as the author can tell) doesn't include the "ustar" signature in its file headers in the created TAR archive. As a result, tardiff treats all these blocks as invalid. Additionally, very old versions of tar (1.12 confirmed, 1.13 is fine) generate spaces (hex 20) instead of NULL bytes (hex 00) in some parts of the file headers, and tardiff wasn't set up to deal with this. This problem hasn't been fixed yet; the author has a potential fix written, but it could cause other problems with valid TAR archives. The author fears that sparse TAR archives, in particular, could be improperly dealt with under the current "fix"; but there could easily be other problems...

Update: Fixing the problem with older tar archives isn't difficult, and I think I have a "solution" of sorts for archives without the file header signatures. I intend to make it a fatal error when one of the archives does not have a signature in its first file header, presenting an error message and a switch to turn off the warning. When this switch is activated, any archives that are missing the first file header's signature will not expect any signature in further headers in that archive, but an archive that includes a signature in the first header will expect one in all subsequent headers. (If the unknown program can "append to" a tar-generated archive, archives so affected will still have problems, though... so perhaps this isn't the best solution.)

At present, to the author's knowledge, new versions of PERL do not cause additional problems to tardiff. However, the author has already been thrown off this rug once before, when he discovered that PERL added automatic "unicode correction" in version 5.006, and the documentation was inaccurate (to put it kindly) about how to turn this "feature" off.

(Also, the author has not tried to crash a system by flooding it with PIDs... recently. However, he has experienced the results of such floods in the past. The server in question then was not Linux, and it didn't crash, but it became very unusable... An absolutely full PID table is nothing to laugh at, especially if the server can't simply be rebooted.)

Last updated 2005 June 6