This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: setup.exe: Invalid or unsupported tar format


"Thrall, Bryan" wrote:

> I've built setup.exe from source (updated today), and the ChangeLog says
> Brian Dessent fixed the "Invalid or unsupported tar format" problem with
> empty tar.bz2 files, but I am still seeing the error popup.
> 
> 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
> http://cygwin.com/ml/cygwin-apps/2008-04/msg00105.html), and diff
> reports the results identical; the file size is the expected 46 bytes.

That fix was for empty bzipped files, i.e. the result after
decompression is a 0 byte file, so it's not exactly relevant to this
situation.

> The setup.exe source (install.cc, Installer::installOne) looks like it
> expects an error peeking from try_decompress in this situation, but
> running in the debugger shows try_decompress->peek() successfully
> reading '0'. Note that if you bunzip2 the empty package, you get a 10K
> tarball which is all zeroes, so success isn't completely unexpected...

This code should not have ever been reached if the file contained a
valid tar header, since archive::extract should not have returned NULL
in that case.  For a valid-yet-empty tar file (i.e. what the 46 byte
thing is supposed to be) archive::extract should succeed but the first
call to next_file_name will return an empty string.

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.  And I
checked all the old existing 46 byte .tar.bz2 files, and they are in
fact just 10k of bzipped zeros.  Sigh.  Why does tar do this?   This
causes ::extract to return NULL (since it looks nothing like a tar file)
but it's also not an empty file, so peek doesn't fail either.

And again, to recap: the reason for generating an error instead of
silently moving on  in this situation was to diagnose the case where the
maintainer used a strange tar implementation to create a package --
without the error the package will be silently skipped which is very
confusing.  But it seems like this nonsense 10k of zeros will have to be
special cased in order to be able to detect the desired error case from
the bogus error case.

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.

Brian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]