X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:from:to:references:in-reply-to
	:subject:date:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=IslnRweD+zHPdnC9
	obNT8eip9LbOTHTDd7XEgju3T4sXn+EvgUGoBGKHItYk4IioRbcU+9snci6pfFrI
	IDCu1zMaDEjEzckgjw4sehF6KlvINr3R8cLfSEqXAqU6uaIRIGzp5jqA/drLltqN
	5M0S+/8p8tLt5LUH6EdDMlhvXJA=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:from:to:references:in-reply-to
	:subject:date:mime-version:content-type
	:content-transfer-encoding; s=default; bh=L/C0kvgTUuHVbypph/lWJx
	qLoRc=; b=ZOYFxLkwN5eDpfZSTKmB4xpCsLkEnny848OyUNhZpadAAXKeRH2lP6
	jabexjPW2SuT0UKBsaVLLI0Yfb3Yt6S19m+djmywrEByy8ucejUmfRRwn765n6qJ
	tm6Jwi9iroYupF3vl5wAVlF9+fO2NctX+eQIzfZIy13x0+EHN7T8Q=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
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
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)
Message-ID:	<5D13B45DBC02439BB6983CB46A306103@skywavemobile.com>
From:	"Stephen Anderson" <stephen DOT rhoderson AT gmail DOT com>
To:	<cygwin AT cygwin DOT com>, "cyg Simple" <cygsimple AT gmail DOT com>
References:	<FDF650EB6B144CDE9983FC655ABFF5FA AT skywavemobile DOT com> <9c8c94a1-2df6-354e-12ed-55d9d19670ca AT gmail DOT com> <D6D912CDA2774E2FB30CA02A2B9467D1 AT skywavemobile DOT com>
In-Reply-To:	<D6D912CDA2774E2FB30CA02A2B9467D1@skywavemobile.com>
Subject:	Re: unzip, find broken by auto handling of .exe file extension
Date:	Fri, 9 Sep 2016 09:18:07 -0400
MIME-Version:	1.0
X-IsSubscribed:	yes

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 AT cygwin DOT 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 AT cygwin DOT 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

- Raw text -