Mail Archives: cygwin/2011/02/25/20:03:58
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
- Raw text -