Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <3EA7F53C.5010405@us.ibm.com>
Date: Thu, 24 Apr 2003 10:31:24 -0400
From: Gary Johnston <gjohnsto AT us DOT ibm DOT com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: unzip - known problem?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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


--
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/