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

Alexander Viro (viro@math.psu.edu)
Tue, 9 Jan 2001 10:00:52 -0500 (EST)


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

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

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.

We could add new syscalls. However, I'm yet to see the real-world situation
where they would be needed enough to warrant their inclusion. And I mean
real-world, not an exercise asking for that functionality. Occam's Razor...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/