From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50280 invoked by alias); 9 Sep 2016 13:18:21 -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 50260 invoked by uid 89); 9 Sep 2016 13:18:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.7 required=5.0 tests=BAYES_40,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=exhibit, HX-Envelope-From:sk:stephen, HX-MSMail-Priority:Normal, terminating X-HELO: mail-oi0-f51.google.com Received: from mail-oi0-f51.google.com (HELO mail-oi0-f51.google.com) (209.85.218.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Sep 2016 13:18:10 +0000 Received: by mail-oi0-f51.google.com with SMTP id q188so25790179oia.3 for ; Fri, 09 Sep 2016 06:18:10 -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:content-transfer-encoding:importance; bh=CbZfX0fKXMOqnt0Pv+PoXGuEUWKiM3xzcHy4aE14CvA=; b=VWNk7tVKwZmXMN7/O7h9oQ+ouskrKFnbkyZxZMaMoDdQzHDE3vMpxyG8QIFCDjP/ka ulzx3ZyRzmsUYgW7nLIQ+G3HUHwYGvtf7lw0Ijw3UqtzrxIrca5aR0Kv63ePNG8iH9K9 5/kE2+V5kgeKsCLCsYV4hg/9JpERgIFkg7iAP2Zx0ZGJmSD+VrM5U6d5wdGUU+czU3Np RtGgWLD0ZxBK7rP9NiR+DaHl9a1cCJGBNK2xY1uEfbCP9BUuVkdDOuXH5oNh+hMUiMhD BXLAL06ntoFytuhXG4nLs65yJxRexPgV+IlMlz/YePoT/Hx/5Yt3Syjk2jeqU56Tv6/D MKUQ== X-Gm-Message-State: AE9vXwPv/ui9XQttgtAIwlpZ0PNN1x21dJmpd8h/kBD0mz9gndyzMRz0Yx9i+wgBGdU6ug== X-Received: by 10.202.253.206 with SMTP id b197mr618007oii.137.1473427088554; Fri, 09 Sep 2016 06:18:08 -0700 (PDT) Received: from WSNETOPS3 (rtr-primus.skywavemobile.com. [209.217.114.195]) by smtp.gmail.com with ESMTPSA id y131sm1635378ioy.29.2016.09.09.06.18.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 09 Sep 2016 06:18:08 -0700 (PDT) Message-ID: <5D13B45DBC02439BB6983CB46A306103@skywavemobile.com> From: "Stephen Anderson" To: , "cyg Simple" References: <9c8c94a1-2df6-354e-12ed-55d9d19670ca@gmail.com> In-Reply-To: Subject: Re: unzip, find broken by auto handling of .exe file extension Date: Fri, 09 Sep 2016 13:18:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00148.txt.bz2 See also: http://stackoverflow.com/questions/32467871/unzip-gives-checkdir-error-directory-exists-but-is-not-a-directory#32468314 The fact that 7z handles this and unzip does not indicates that the problem is fixable.. sja -----Original Message----- From: Stephen Anderson Sent: Friday, September 02, 2016 4:19 PM To: cygwin@cygwin.com ; cyg Simple Subject: Re: unzip, find broken by auto handling of .exe file extension 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 -- 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