From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39360 invoked by alias); 2 Sep 2016 20:20:07 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 39339 invoked by uid 89); 2 Sep 2016 20:20:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=H*x:16.4.3528.331, H*UA:16.4.3528.331, HX-MimeOLE:V16.4.3528.331, sja X-HELO: mail-it0-f51.google.com Received: from mail-it0-f51.google.com (HELO mail-it0-f51.google.com) (209.85.214.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 02 Sep 2016 20:19:56 +0000 Received: by mail-it0-f51.google.com with SMTP id i184so57911838itf.1 for ; Fri, 02 Sep 2016 13:19:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:in-reply-to :subject:date:mime-version:importance; bh=aTAfR37V34PgOI8cgHOoINp5/lEFvURgwPmYL2xPa5M=; b=XQLTS2XI+s0w1+6WVEmXiDg7GvE78z/sVB4XRrgYlHj5QwGwxChTEyho4q6wGv7Lz6 sKzjJf4h518m5OmzJFb1GP/2yYt+QkN1mpfy3+tEO409v6gPi9pbg17nnoHVyKtTrVZ6 jzr5yY3WOmayiSavFWqbyrVMjy4dt/hpz+NqNU0bDvfsSc2WsJHaJpMqbKQ+O4JYOxIW e83jz95cLNjWWhJ2w3CkRCYWPipprxrvXcCpz8fbHRcMJNMd2HgVN5Dg36/f6F3dt6Cn oODISVUcrrMIJb3Xt6/TPZGGFkrRWJ1G/T6aVFcUDl6Z/Ld0XnhNzTO/bBhQWfmE49B2 dX6A== X-Gm-Message-State: AE9vXwPyKY2bOKPuhhV3CwQR4KRDlVaC8r+8S1n8PTutFXQ3zptWTwF1xoC9l741+pH8Zg== X-Received: by 10.107.139.195 with SMTP id n186mr1224119iod.185.1472847594469; Fri, 02 Sep 2016 13:19:54 -0700 (PDT) Received: from WSNETOPS3 (rtr-primus.skywavemobile.com. [209.217.114.195]) by smtp.gmail.com with ESMTPSA id b10sm391719ioe.9.2016.09.02.13.19.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 02 Sep 2016 13:19:53 -0700 (PDT) Message-ID: From: "Stephen Anderson" To: , "cyg Simple" References: <9c8c94a1-2df6-354e-12ed-55d9d19670ca@gmail.com> In-Reply-To: <9c8c94a1-2df6-354e-12ed-55d9d19670ca@gmail.com> Subject: Re: unzip, find broken by auto handling of .exe file extension Date: Fri, 02 Sep 2016 20:20:00 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000A_01D20535.D5D24AE0" X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00030.txt.bz2 ------=_NextPart_000_000A_01D20535.D5D24AE0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit Content-length: 3581 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 ------=_NextPart_000_000A_01D20535.D5D24AE0 Content-Type: application/octet-stream; name="Test_ExeAutoExpand.rb" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Test_ExeAutoExpand.rb" Content-length: 3221 #!/usr/bin/ruby=0A= # $URL: http://localhost:8008/svn/Research/CygwinAutoexeExpansionProblem/Te= st_ExeAutoExpand.rb $=20=0A= # $Revision: 74 $=0A= # $Date: 2016-09-02 14:49:50 -0400 (Fri, 02 Sep 2016) $=0A= # $Author: stephen_a $=0A= require 'minitest/autorun'=0A= require 'fileutils'=20=0A= =0A= # Lots of straight-forward tests, success path only.=0A= class Test_ExeAutoExpand < Minitest::Test=0A= =20=20=0A= # Prepare common stuff for test execution.=0A= def setup=0A= # Create a hierarchy like this:=0A= # testAutoExeExpansion=0A= # |=0A= # - test.exe=0A= # + test/=0A= # |=0A= # - test.exe=0A= #=0A= %x(rm -rf testAutoExeExpansion*)=0A= %x(mkdir -p testAutoExeExpansion)=0A= %x(mkdir -p testAutoExeExpansion/test)=0A= %x(touch testAutoExeExpansion/test.exe)=0A= %x(touch testAutoExeExpansion/test/test.exe)=0A= end=0A= =0A= # Do common stuff to wrap up tests.=0A= def teardown=0A= end=0A= =0A= # Check that zip/unzip with default ordering works=0A= # The default ordering puts directory first and seems=0A= # to cause no problems.=0A= def test_unzipDefault=0A= %x(zip -r testAutoExeExpansion.zip testAutoExeExpansion)=0A= assert_equal(0, $?.exitstatus, "zip failed!")=0A= %x(rm -r testAutoExeExpansion/)=0A= %x(unzip -ouq testAutoExeExpansion.zip)=0A= assert_equal(0, $?.exitstatus, "unzip failed!")=0A= end=0A= =0A= # Check that zip/unzip with exe file in archive first=0A= # This causes problems.=0A= def test_unzipExeFirst=0A= %x(zip testAutoExeExpansion.zip testAutoExeExpansion/test.exe)=0A= assert_equal(0, $?.exitstatus, "zip1 failed!")=0A= %x(zip -r testAutoExeExpansion.zip testAutoExeExpansion/test/)=0A= assert_equal(0, $?.exitstatus, "zip2 failed!")=0A= %x(rm -r testAutoExeExpansion/)=0A= =0A= %x(unzip -ouq testAutoExeExpansion.zip)=0A= assert_equal(0, $?.exitstatus, "unzip failed!")=0A= end=0A= =0A= # Check that zip/unzip with exe file in archive first, exclude problemati= c directory workaround=0A= # This causes problems.=0A= def test_unzipExeFirstExclude=0A= %x(zip testAutoExeExpansion.zip testAutoExeExpansion/test.exe)=0A= assert_equal(0, $?.exitstatus, "zip1 failed!")=0A= %x(zip -r testAutoExeExpansion.zip testAutoExeExpansion/test/)=0A= assert_equal(0, $?.exitstatus, "zip2 failed!")=0A= %x(rm -r testAutoExeExpansion/)=0A= =0A= %x(unzip -ouq testAutoExeExpansion.zip -x testAutoExeExpansion/test/ )= =0A= assert_equal(0, $?.exitstatus, "unzip failed!")=0A= end=0A= =0A= # Check that find can locate and remove directory with co-located exe fil= e=0A= # This causes problems.=0A= def test_findrmr=0A= %x(find testAutoExeExpansion -path testAutoExeExpansion/test -type d -e= xec rm -r {}/ \\;)=0A= assert_equal(0, $?.exitstatus, "find failed!")=0A= end=0A= =0A= # Check that find can locate and remove directory with co-located exe fil= e=0A= # This causes problems.=0A= def test_findrmdir=0A= %x(find testAutoExeExpansion -path testAutoExeExpansion/test -type d -e= xec rmdir {}/ \\;)=0A= assert_equal(0, $?.exitstatus, "find failed!")=0A= end=0A= =0A= end=0A= =0A= ------=_NextPart_000_000A_01D20535.D5D24AE0 Content-Type: text/plain; charset=us-ascii Content-length: 218 -- 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 ------=_NextPart_000_000A_01D20535.D5D24AE0--