This is the mail archive of the cygwin@cygwin.com 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: unzip - known problem?


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


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