Thanks for looking at the problem. Unfortunately not resolved...
1. As demonstrated by the provided ruby test case, it is very possible to have a directory and base filename be the same. Open bash and try it.
$ mkdir mything $ touch mything.exe $ ls mything* mything.exe mything: $2. Even if cygwin somehow prevented it (it can't), zip archives do not preclude the presence of a base filename with exe extension and same directory name.
3. The problem is not simply exe - batch files (.bat, .cmd), powershell (.ps1) and others are automatically picked up by cmd.exe processing, and can all have common base names.
4. I tried unzip -x and it does not workaround the problem. 7z remains my workaround and the only one I have found so far.
5. Terminating the find -path with / results in 'find: warning: -path testAutoExeExpansion/test/ will not match anything because it ends with /'.
6. Terminating the target with / does not help. 7. Rmdir fails with 'directory not empty'.8. I am NOT trying to run the executable, so the globbing should NOT automatically be expanding 'test' to match 'test.exe'. I would think that the only utilities that really should do that would be 'which', 'whereis' or shell command completion (not file completion).
Attached updated test case. sja-----Original Message----- From: cyg Simple
Sent: Friday, September 02, 2016 2:40 PM To: cygwin@cygwin.com Subject: Re: unzip, find broken by auto handling of .exe file extension On 9/1/2016 12:00 PM, Stephen Anderson wrote:
I am in the process of importing zip archive contents into an SVN repo
and have encountered problems when unzip-6.00 expands an archive
containing an executable file in a directory that contains a
subdirectory with the same base name as the executable. If the
executable happens to occur after the subdirectory, unzip works, however
if the executable is first, unzip fails with the error:
checkdir error: testAutoExeExpansion/test exists but is not directory
unable to process testAutoExeExpansion/test/.
How can a directory and a file of the same name exist? It can't and because Cygwin stats the foo.exe to be foo then that is the filename comparison.
Luckily I am able to use 7z extract, which does not exhibit the unzip problem and even allows me to exclude the culprit subdirectory (which luckily contains nothing I am interested in).
Unzip has the -x option to exclude archive items.
In the process of trying to solve this problem, I used find-4.6.0 to try and delete the subdirectory after extracting with 7z to no avail. Even preceding the path match with a type directory spec find gets confused (so did the svn commit BTW).
Did you trail the name with / for the delete? The rmdir command should work. You would use the -exec option with find to execute rmdir rather than the delete function of find.
The enclosed ruby unit test reproduces the minimal circumstances of the issue for both unzip and find. It is likely that this is a common problem somewhere in the bowels of file 'globbing' in cygwin only.
Yes and one that allows the stat of foo.exe by foo only so that it can launch the application. It has existed since the beginning of Cygwin and I doubt it will ever be resolved without requiring the full file name for executables. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Test_ExeAutoExpand.rb
Description: Binary data
-- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
