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:date:message-id:from:reply-to:to:subject
	:references:in-reply-to:content-type; q=dns; s=default; b=fkR1e7
	2yfxOj+o3eDsPBfDfMA1DhSW6lJ/7VN3k9/2rA5Rc8EmDhNNaYKo8ELIvsefE1l4
	O8JjBracEXCD7VMWft689gvYYAP2fjNi0eJHqaVQu6koppPov/VPjgy3rZ0pdNS1
	OD2tzHSq/gsw8WHL/anQyWC53HQi2U756vhQA=
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:date:message-id:from:reply-to:to:subject
	:references:in-reply-to:content-type; s=default; bh=ApMXCgMThNoh
	e4EBiXSKlmFZ0a8=; b=q6Q/yPDnMiP7ynbun2tf2sVPqxPIfPYMXIdMc+HpsF4P
	1fqjcEkkBt8JgdU7UE3KPapuoRczNOe2IxWrSFRkjCvyb36dxKDEGSzixk67eyPv
	VB7I1aoJG15FK5vTxYK+6N1wvhR/415M2H3ym7LiwQ/u07Zollradjuio7sQMxY=
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-Spam-SWARE-Status:	No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NORMAL_HTTP_TO_IP,NUMERIC_HTTP_ADDR,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=D*@, his
X-HELO:	lb1-smtp-cloud9.xs4all.net
Date:	Sun, 22 Sep 2019 11:47:25 +0200
Message-ID:	<19237db2338c900d4faae7d771b6156d@smtp-cloud9.xs4all.net>
From:	Houder <houder AT xs4all DOT nl>
Reply-To:	cygwin AT cygwin DOT com
To:	cygwin AT cygwin DOT com
Subject:	Re: Solved. Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...
References:	<8e310c59702b57501ca2fd80edf19d2e AT smtp-cloud9 DOT xs4all DOT net>
In-Reply-to:	<8e310c59702b57501ca2fd80edf19d2e@smtp-cloud9.xs4all.net>
User-Agent:	mua.awk 0.99

Nothing new here; only correction of mistakes that I made (I decided
to review my e-mail because Ken Brwon took an interrest in the subject
matter).

On Fri, 06 Sep 2019 23:53:05, Houder  wrote:
> To those still interested! :-P
[snip]

> While I took a closer look at the source code, I found a BUG in
> path_conv::check() in winsup/cygwin/path.cc
> 
>     https://cygwin.com/ml/cygwin/2019-08/msg00418.html <==== wrong
>     ( Date: Sun, 01 Sep 2019 19:38:11 +0200 )

Correction:
https://cygwin.com/ml/cygwin/2019-09/msg00001.html

[snip]

> On September 3rd, I discovered that dropping Eric B.'s code snippet,
> would introduce a BUG:
> 
>     https://cygwin.com/ml/cygwin/2019-09/msg00015.html
>     ( Date: Tue, 03 Sep 2019 10:39:54 +0200 )
> 
> 64-@@ ln -s aap noot
> ..
> 64-@@ rmdir aap
> 64-@@ mkdir noot
> mkdir: cannot create directory ‘noot’: File exists
> 64-@@ mkdir noot/ <==== Whao! So that is what Eric indicated in his commit!
> 64-@@ ls -ld aap <==== WRONG! WRONG!
> drwxr-xr-x+ 1 Henri None 0 Sep  3 10:28 aap
> 
> Different from Posix, Linux does not allow the creation of the directory
> aap ...   (btw, neither should rmdir delete an existing directory aap if
> noot/ is specified)

Correction:
Linux is in agreement w/ Posix.
Cygwin is NOT in agreement w/ Posix (and Linux)i wrt to rmdir(2).

> While waiting for a reaction by Eric Blake, I decided to take a closer
> look at path_conv::check() ... Could a solution be found in this method?
> 
> (path arguments to (all?) commands are processed by this method)
> 
> Basically, this method consists of a 'double loop', as follows:
> 
>     for (;;) // outer loop
>       for (;;) // inner loop
> 
>  - the inner loop tests whether or not a path component is a symlnk
>  - if it is, the outer loop is reentered, where the symlnk part of
>    the path is replaced by the target
>  - finally, the algorithm bails out of both loops if a "real" path
>    is found (or not)
> 
> Or something very near to this explanation ...
> 
> In case the last component is a symlnk, the name of the symlnk is
> saved internally if the path had not been specified w/ a trailing
> slash. Otherwise the name of the target is saved internally.

Correction:
A symlnk is always followed if the pathname ends w/ a trailing slash;
if not, it depends on what the system call specified when it invoked
"path resolution" (path_conv::check() ).
If the system call specified "do not follow", "path resolution" does
not follow the symlnk (again, if path does NOT end w/ a trailing /).

> In short, there is a basic difference between specifying a path
> w/ a trailing slash or not ...

Correct! Look at how the response is different between stat final
and stat final/ in case of a symlnk.
(stat(1) basically calls lstat(2), which directs path resolution
 NOT to follow a symlnk; however that directive is ignored by path
 resolution if the pathname ends w/ a slash)

mkdir(2) and rmdir(2) are exceptions, in that these syscalls must
strip trailing slashes; they must also specify "do not follow".

The reason is, that these syscalls must not accept a symlnk as an
argument.

Henri

=====


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