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. 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... $ cygcheck -cd | grep 'bzip\|tar\|cygwin' bzip2 1.0.3-2 cygwin 1.5.25-7 mingw-bzip2 1.0.3-2 tar 1.19-1 Am I missing anything? I'm not sure the best way to fix this; the following patch worked, but seems unlikely to actually be correct in all cases. Is an empty tarball the only case where the peek value will be zero? Index: install.cc =================================================================== RCS file: /cvs/cygwin-apps/setup/install.cc,v retrieving revision 2.83 diff -u -p -w -r2.83 install.cc --- install.cc 9 Apr 2008 02:25:27 -0000 2.83 +++ install.cc 5 May 2008 20:15:13 -0000 @@ -259,7 +259,7 @@ Installer::installOne (packagemeta &pkgm /* Decompression succeeded but we couldn't grok it as a valid tar archive. */ char c; - if (try_decompress->peek (&c, 1) < 0) + if (try_decompress->peek (&c, 1) < 0 || !c) // assume 0 indicates empty tarball /* In some cases, maintainers have uploaded bzipped 0-byte files as dummy packages instead of empty tar files. This is common enough that we should not treat this as an -- Bryan Thrall FlightSafety International [EMAIL PROTECTED]
