[lkml]   [2000]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BUG] Inconsistent behaviour of rmdir

On Thu, 16 Nov 2000, Jean-Marc Saffroy wrote:

> On Thu, 16 Nov 2000, Linus Torvalds wrote:
> > The cwd is not the problem. The '.' is.
> >
> > The reason for that check is that allowing "rmdir(".")" confuses a lot of
> > UNIX programs, because it wasn't traditionally allowed.
> This is a point I don't understand here : do you mean that they are
> confused if they can rmdir "." but not if they can rmdir their cwd
> differently ? What's the difference ?

rmdir() is _not_ "kill the directory identified by name and remove all
links to it". It's "remove a given link and .. in directory pointed
by it, then schedule directory for removal".

BTW, cwd is irrelevant - /tmp/foo/. would demonstrate the same behaviour.

It becomes really obvious when you look at rename() - you act on links,
not on inodes. The only reason why we could try to overload that for
directories was that there is a special link - one from the parent.
However, _finding_ said link in race-free way is extremely nasty.
Especially for cases like /tmp/foo/. where /tmp/foo is a symlink to
/tmp/bar/baz. AFAIK Linux was the only system that tried to be smart
in that area. And that attempt was _not_ successful - there were rather
interesting races around the thing. Besides, we clearly violated
all relevant standards - rmdir() and rename() are required to fail
if the last component of name happens to "." or "..".

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:47    [W:0.162 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site