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]

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


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