On Mon, Jan 08, 2001 at 11:50:44PM +0100, Andries.Brouwer@cwi.nl wrote:
> From: Andrea Arcangeli <andrea@suse.de>
>
> > 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
>
> That is the SUSv2 text, one of the ingredients for the new
> POSIX standard. I quoted the current Austin draft, the current
> draft for the next version of the POSIX standard.
>
> Quoting a text fragment:
>
> The rmdir( ) function shall remove a directory whose name is given by
> path. The directory is removed only if it is an empty directory.
> If the directory is the root directory or the current working
> directory of any process, it is unspecified whether the function
> succeeds, or whether it shall fail and set errno to [EBUSY].
> If path names a symbolic link, then rmdir( ) shall fail and
> set errno to [ENOTDIR]. If the path argument refers to a path
> whose final component is either dot or dot-dot, rmdir( ) shall
> fail. ...
I trust your specs said so, however I'm not sure which are the specs
we should follow for Linux.
At least for LFS 2.2.x fixage I always followed the SuSv2 specs and they
doesn't even say that rmdir can return -EINVAL. So returning -EINVAL is wrong
in first place according to SuSv2.
> from the directory "foo", but rmdir("foo/.") does not finish
> by removing the name "." from the directory "foo".
Sure. Also `rmdir .` doesn't mean remove "." from current directory but it
means "remove the directory pointed out by path `.'". The kernel/We definitely
knows which is such directory. That is in sync with the specs: "The rmdir()
function removes a directory whose name is given by path". You agree that the
path "." identifys one directory.
Andrea
-
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/
This archive was generated by hypermail 2b29 : Mon Jan 15 2001 - 21:00:19 EST