On Mon, Jan 08, 2001 at 09:56:18PM +0100, [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
