setup.exe: Invalid or unsupported tar format

Brian Dessent
Tue May 6 20:42:00 GMT 2008

Christopher Faylor wrote:

> Yes, I'm confused by this.  I did replace all of the zero length tar files
> with the 46 byte versions.  That's what I've always done when creating an
> empty package.

Here is a summary of the situation:

The current stable/release version of setup will never warn if it can't
understand a package, it will just silently skip it.  Mostly, this is
what you want, as it means it will cope just fine with both the 14b and
46b packages.

However a while ago someone reported that a package wasn't installing
and after investigation it was because the maintainer had used something
like cmake with its own libtar implementation that used an incompatible
magic.  Setup was silently refusing to install the package even though
everything indicated that it was to be installed -- very confusing.  I
added support for this new magic value and rewrote the tar checking code
to explicitly warn if it cannot grok a package.  This change existed
only in testing/snapshot versions so few people would have experienced

Unbeknownst to me at the time, this meant it would report on both the
14b packages (since they contain nothing after decompression) and the
46b packages (since they don't actually contain a tar header but 10k of
\0 which is unrecognisable to setup as a valid tar header.)  I admit
that I don't regularly install packages from _obsolete so I never saw it
in any of my testing.

Some time later someone reported using a setup snapshot and seeing the
warning for an empty 14b package.  At the time I attributed this to the
14b package not being a 46b package, and added code to setup to skip the
14b package without a warning, assuming incorrectly that the 46b case
also worked as no one had reported that -- until now.

What I intend to do is add another special-case for checking that if the
first 512 bytes are all zeros to assume it's an empty tar file and
suppress the warning.  This will mean that both 46b and 14b packages are
correctly handled, as well as still preserving the warning if a real
package is unrecognisable.  But until I can add that, if you are using a
snapshot version only the 14b packages will be correctly handled; the
46b ones will warn.  This is mostly just a nuisance as installation
continues after the warning is dismissed and it's not like you're
missing anything from the empty package, but it's a nuisance nonetheless
and setup ought to be able to handle both types of empty package.

I don't think there's any need to convert anything on the mirrors again
because the next actual release version of setup should cope with both,
and people using snapshots should be able to deal.


More information about the Cygwin-apps mailing list