Re: `rmdir .` doesn't work in 2.4

[Albert D. Cahalan]

Alexander Viro writes:
> On Tue, 9 Jan 2001, Albert D. Cahalan wrote:
>> Alexander Viro writes:
>>
>>> [...] If you really need to destroy the directory
>>> that happens to be your pwd - sorry, no reliable way to do that without
>>> interesting locking. On _any_ UNIX out there. 2.2 included. It will
>>> happily give you -ENOENT and refuse to perform the action above in
>>> case if some other process renames your pwd. Yes, for rmdir(".");
>>
>> Well, this bites.
>>
>> Locking guess: use a global read-write lock, with the "write" case
>> being deletion of "." and the "read" case being everything else.
>> You could have one lock per CPU, with the writer needing to grab all
>> of them in order. So removal of "." pays the cost.
>
> It's _so_ far from the SMP cache issues that it's not even funny.
> So reference to brw-locks is completely bogus. What you are proposing
> is to serialize rmdir() and rename() (including lookups) wrt rmdir
> and rename. Globally. Fun, fun...

As long as nobody tried to remove ".", nothing is serialized.
You can do your lookups in parallel since they can all grab
the read lock at once.

If you prefer some pentuple_down thing though, cool.

>> If the standards gripe, well, rmdot() is a nice name.
>
> If anything, frmdir() might be a better name. However, it's really
> inconsistent with the whole namespace-modifying stuff. You don't
> have flink(fd, newname). frename() and funlink() are not even
> funny - _which_ link would you want to be renamed/removed?

Linux can tell where you got the "f" from in the first place.
Deleted files could cause an error, or turn frename() into flink()
and return success for funlink().

> Filesystem consists of two types of objects - files (and that includes
> directories, etc.) and links. Pathname can be evaluated to link and to
> file. Namespace syscalls (creat()/mkdir()/mknod()/symlink()/link()/
> unlink()/rmdir()/rename()) operate on links. open(), truncate(), stat(),
> lstat(), etc. operate on files - completely different can of worms.
>
> 2.2 tried (without success) to make rmdir() and some cases of rename() act
> on files. Notice that if you have /foo as pwd, "." and "/foo" will evaluate
> to the same file, but to different links. That's what it's really about.

The whole "." and ".." mess is 100% special case to begin with,
so this argument doesn't make sense. The mess already gives
us a link that gets replaced when some other link is renamed,
and two links that get unlinked when something else is unlinked.