This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Please test latest developer snapshot


Am 26.02.2011 01:24, schrieb Vorfeed Canal:
On Mon, Feb 21, 2011 at 6:20 PM, Thomas Wolff<towo@towo.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]