Mail Archives: cygwin/2003/04/24/11:09:12
----- 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/
- Raw text -