Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Originating-IP: [12.254.208.112]
X-Originating-Email: [mgainty AT hotmail DOT com]
From: "Martin" <mgainty AT hotmail DOT com>
To: "Gary Johnston" <gjohnsto AT us DOT ibm DOT com>, <cygwin AT cygwin DOT com>
References: <3EA7F53C DOT 5010405 AT us DOT ibm DOT com>
Subject: Re: unzip - known problem?
Date: Thu, 24 Apr 2003 09:08:43 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Message-ID: <Law10-OE50CESWs38TR000054c5@hotmail.com>
X-OriginalArrivalTime: 24 Apr 2003 15:09:03.0098 (UTC) FILETIME=[711145A0:01C30A73]


----- Original Message ----- 
From: "Gary Johnston" <gjohnsto AT us DOT ibm DOT com>
To: <cygwin AT cygwin DOT com>
Sent: Thursday, April 24, 2003 7:31 AM
Subject: unzip - known problem?


> Let's say I have a .zip file, test.zip, that contains the following:
> test/cat.exe
> test/cat/mouse.exe
> 
> If I do "unzip test.zip" (in an otherwise empty directory), I get the 
> following error:
>     checkdir error:  test/cat exists but is not directory
>                      unable to process test/cat/.
> 
> Has anyone else seen this kind of behavior?  I searched the FAQ and 
> mailing list archives, but couldn't find anything that seemed relevant. 
>   Native Windows unzippers (like WinZip, pkzip, etc.) have no problem 
> with it.
> 
> For now, I've had to work around the problem by doing a 2-phase unzip 
> (e.g., effectively do "unzip test.zip -x test/cat.exe" followed by 
> "unzip test.zip test/cat.exe").  Ugly and fragile.  Another workaround 
> would be to ensure that .exe(s) are added to the .zip *after* the files 
> in the similarly named directory(ies), but this is not an option for me 
> in this case because I am not the producer of the .zip files.
> 
> <reckless-conjecture>
> Here's what seems to be happening (I'm kind of guessing here). First, 
> unzip extracts test/cat.exe successfully.  Then, when it gets to 
> test/cat/mouse.exe, it tries to determine if it needs to create 
> directory cat, so it checks for the existence of cat (via stat()?).  My 
> guess is that whatever it is that unzip is using to determine the 
> existence of cat is "seeing" cat.exe and, (in an attempt to be helpful 
> to shells, exec(), etc. about finding .exe files invoked w/o the .exe 
> extension) reports that cat exists (and is a file).  So, unzip complains.
> </reckless-conjecture>
> 
> <jumping-the-gun>
> I'm kind of new to cygwin, but I suspect that this behavior of stat() 
> (or whatever) re .exe files is that way very much on purpose in order to 
> allow existing code and shell scripts to run unmodified under cygwin, so 
> "fixing" stat() is not an option.  Therefore, maybe there needs to be 
> some workaround/patch to the cygwin version of unzip to handle this 
> situation.  Perhaps there needs to be some sort of flag that can be used 
> to turn off this behavior in stat() when necessary (which unzip could 
> exploit).
> </jumping-the-gun>
> 
> Gary Johnston
> WebSphere Studio Struts Tools Development
> IBM Software Group, Research Triangle Park, NC
> 
agreed stat should be skipped
Has IBM Come up with a port for cygwin?
Martin

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/