setup.exe: Invalid or unsupported tar format

Eric Blake
Tue May 6 02:14:00 GMT 2008

Hash: SHA1

According to Brian Dessent on 5/5/2008 3:11 PM:
|> I have an empty meta-package to pull in other packages copied from one
|> of the _obsolete packages. I understand these are created via 'tar -T
|> /dev/null -cjf foo.tar.bz2' (see
|>, and diff
|> reports the results identical; the file size is the expected 46 bytes.

It sounds like we need to replace all the 46-byte files with 14 byte ones?
~ But the empty file is technically not a valid tar file, since it lacks
the required trailing blocks.

| But it seems that "tar -T /dev/null" doesn't in fact produce anything
| resembling a valid tar file, it simply spits out 10k of zeros.

Perhaps this is worth a question on the upstream tar list?  According to, it looks
like a valid tar file can exist without files, but needs 2 blocks of all 0
bytes to identify the end of the tar file.  And since the default tar
configures with tar options of -b20, I'm actually surprised it's not 20k
of NUL bytes (2 blocks * 20 units of 512 per block).  You can reduce the
size of a valid tarball with 'tar -b1 -c -T /dev/null', but that's still a
1k file of all NULs.

| In the mean time, I suggest you use a real empty file as workaround
| (i.e. bzip2 </dev/null >file.tar.bz2) as that should correctly be
| detected as an empty package if you're using the current setup.

By the way, the special 1.7 setup has this error enabled by default,
making it report failure on any attempt to install packages like 'gcc'
which are empty tarball placeholders with dependencies elsewhere when
trying out the 1.7 tree.

- --
Don't work too hard, make some time for fun as well!

Eric Blake   
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Mozilla -


More information about the Cygwin-apps mailing list