Re: Problems installing from Cygwinports

[Jon TURNEY <jon.turney@dronecode.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]

On 31/03/2011 06:15, Yaakov (Cygwin/X) wrote:
> As a potential setup.exe bug, redirecting to cygwin-apps.
> 
> On Thu, 2011-03-31 at 00:54 +0200, Angelo Graziosi wrote:
>> It is sometime I have installed a few packages from Cygwinports 
>> (QT,GCC), but today upgrading (mainly *QT*-4.7.2-1 and *mesa*-7.10.1-2) 
>> 'setup.exe' seems to hang in extracting /usr/include/GL/glxext.h from 
>> libGL-devel-7.10.1-2.
> 
> Confirmed.
> 
> (The tarball in question is here:)
> ftp://ftp.cygwinports.org/pub/cygwinports/release-2/_DISTRO_/X.Org/mesa/libGL-devel/libGL-devel-7.10.1-2.tar.bz2
> 
>> Result: my hard drive (C:) is almost full, X does not start any more and 
>> I can use only Cygwin.bat and mintty. To be short, my Cygwin 
>> installation is broken :(
> 
> Start by deleting /usr/include/GL/glxext.h, that will free up your hard
> drive.  Then re-run setup, choosing to KEEP libGL-devel instead of
> upgrading.
> 
> Now, as for the cause, the only thing I can think of is that I just
> started using pbzip2 for compression in cygport[1].  The bz2's are
> supposed to be fully compatible, and neither Cygwin nor MinGW bzip2 have
> any problems with the tarball in question.
> 
> So my wild guess is that setup uses libbz2 in a way which is
> incompatible with pbzip2-compressed tarballs, as unlikely as it seems.  
> 
> Can any setup.exe authors shed any light on this?

I do actually want to install that package, so I took a brief look at this:

The first problem is that .bz2 file and the decompressor don't like each
other. The decompressor reports the stream has ended partway through
decompressing glxext.h.  It's very mysterious that it should fail but bunzip2
has no problems with the same file.

The second problem is a setup bug: If we get an unexpected short read from the
archive stream decompressor, we'll sit in an infinite loop writing garbage to
the output file 5 bytes at a time.  A patch is attached which fixes that, but
since these errors are  unreported (see comment in io_stream::copy), we just
stop expanding the archive, leaving an incomplete glxext.h

[-- Attachment #2: 0001-Don-t-hang-if-something-goes-wrong-reading-from-a-ta.patch --]
[-- Type: text/plain, Size: 1577 bytes --]

From 3ca6eaca538d496867ac4e5e9faf2cf51162ad2f Mon Sep 17 00:00:00 2001
From: Jon TURNEY <jon.turney@dronecode.org.uk>
Date: Thu, 31 Mar 2011 14:45:47 +0100
Subject: [PATCH] Don't hang if something goes wrong reading from a tar archive

Returning EIO (a small positive integer) as the result of archive_tar_file::read()
on an error isn't a good idea, it's indistinguishable from successfully reading
a small number of bytes.

This causes io_stream::copy() to spin forever if it's reading from an archive stream
which terminates unexpectedly early, which can happen on an decompression error.

So, return 0 instead

2011-03-31  Jon TURNEY  <jon.turney@dronecode.org.uk>

	* archive_tar_file.cc (read, peek): Return 0 on an error,
	not EIO.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
---
 archive_tar_file.cc |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/archive_tar_file.cc b/archive_tar_file.cc
index 29a2df7..ed6e515 100644
--- a/archive_tar_file.cc
+++ b/archive_tar_file.cc
@@ -65,7 +65,7 @@ ssize_t archive_tar_file::read (void *buffer, size_t len)
 	  /* unexpected EOF or read error in the tar parent stream */
 	  /* the user can query the parent for the error */
 	  state.lasterr = EIO;
-	  return EIO;
+	  return 0;
 	}
     }
   return 0;
@@ -96,7 +96,7 @@ ssize_t archive_tar_file::peek (void *buffer, size_t len)
 	  /* unexpected EOF or read error in the tar parent stream */
 	  /* the user can query the parent for the error */
 	  state.lasterr = EIO;
-	  return EIO;
+	  return 0;
 	}
     }
   return 0;
-- 
1.7.4