X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0	tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <4D685151.5020602@towo.net>
Date: Sat, 26 Feb 2011 02:03:13 +0100
From: Thomas Wolff <towo AT towo DOT net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Vorfeed Canal <vorfeed DOT canal AT gmail DOT com>, cygwin AT cygwin DOT com
Subject: Re: Please test latest developer snapshot
References: <20110217120400 DOT GB29762 AT calimero DOT vinschen DOT de>	<4D600C0A DOT 9080305 AT etr-usa DOT com>	<4D6273C4 DOT 9050406 AT redhat DOT com>	<4D6282CF DOT 1000606 AT towo DOT net> <AANLkTikbs8k+V1+74jmdvAUynM_-2HZOJ_yqYEN2DF5z AT mail DOT gmail DOT com>
In-Reply-To: <AANLkTikbs8k+V1+74jmdvAUynM_-2HZOJ_yqYEN2DF5z@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
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

Am 26.02.2011 01:24, schrieb Vorfeed Canal:
> On Mon, Feb 21, 2011 at 6:20 PM, Thomas Wolff<towo AT towo DOT net>  wrote:
>> And this is not an artificial limitation but there is no way that this
>> could conceivably work.
> What do you mean "there is no way that this could conceivably work"?
>
> It worked in Linux till it was explicitly forbidden...
>
> See here, for example: http://lkml.org/lkml/1997/9/12/100
No, what used to work (and didn't work in cygwin for a while) is that 
the current directory of some process is removed, not mentioning how it 
could be removed. It cannot be removed by "rmdir ." for the reasons I 
mentioned. It can only be removed by using its full path, or relative 
path from its parent directory. The parent directory must be referred 
explicitly, otherwise it cannot work - because, as I tried to explain, 
the semantics of removing a directory entry (whether file or 
subdirectory) could not be established.

>> By Unix design, removing a file or directory basically means removing
>> its entry from its parent directory, so it is not an operation on the
>> file in the first place (or on the target directory in this case).
> Well, yeah - and this explains all subsequent effects. Directories are not
> files, directory can only have one name at most so there are no confusion.
Actually, in traditional Unix terminology, directories were also special 
files; moreever, there could even be hard links of directories - but 
that doesn't contribute to the issue.

>> The parent directory is obviously needed by design, thus "." is not
>> something that could ever be removed (from where?).
>  From filesystem?
Which means from its parent directory because that concept is a core 
part of the Unix filesystems.
> This artificial limitation was added to POSIX (and
> later to Linux) to fix some old broken scripts. I'm not sure if it was
> good idea or not, but it's written in a standard now so that's how it
> works.
>
> But yes, it IS quite artificial limitation:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=fs/namei.c;h=0087cf9c2c6bccaf99000fbd0bfe95257549d81b;hb=HEAD#l2866
>
> As you can see the only reason you can not rmdir(".") and then rmdir("..")
> is because it's quite explicitly checked for to satisfy POSIX.
This conclusion is not correct. The code you seem to refer to is just a 
way of handling an error that would otherwise go unhandled and produce 
problems. Error handling is not a limitation. Further down in the code, 
where the actual removal is invoked, the code needs the parent directory 
which it would not have in the case guarded by the error checking.

Thomas

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