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

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 09:56:18PM +0100, [e-mail] wrote:
> You think that it fails with EBUSY. That would be allowed but not required:
> 
> [EBUSY]: The directory to be removed is currently in use by
>          the system or some process and the implementation
>          considers this to be an error.
> 
> Here we are free to consider this "in use" an error or not.

I think the above is to allow implementations without something like our dcache
to not be declared "broken" w.r.t. specs.

> But in fact it fails with EINVAL, and
> 
> [EINVAL]: The path argument contains a last component that is dot.

I can't confirm. The specs I'm checking are here:

	http://www.opengroup.org/onlinepubs/007908799/xsh/rmdir.html

They definitely don't say that `rmdir .` must return -EINVAL.

> Indeed, rmdir("P/D") does roughly the following:
> (i) check that P/D is a directory
> (ii) check that P/D does not have entries other than . and ..
> (iii) delete the names . and .. from P/D
> (iv) delete the name D from P

The definition of rmdir according to 2.2.19pre6 and the single unix
specification version 2 is this:

	int rmdir(const char *path);

	DESCRIPTION
		The rmdir() function removes a directory whose name is given by
		path. The directory is removed only if it is an empty
		directory. 

That is strightforward. It doesn't talk about (iv).

> In cases where hard links to directories are permitted,
> it is not even clear we can talk about "the parent directory".

Hardlinks have nothing to do with `rmdir .`. See rmdir . as the equivalent
pointed out by Alexander: "rmdir `pwd`".  `pwd` returns the same thing
regardless the current directory has nlink > 1 or not (even if it has
nlink = 0 infact). The parent directory is still identified as "`pwd`/.." (or
in kernel terms read_lock(current->fs->lock); current->fs->pwd->d_parent).
hardlinks (of files or directories) only matters at the inode level, not at the
dentry level.

Andrea