Re: [Fwd: [bug #6047] rm -f "" prints diagnostic message under the Hurd]

[Marcus Brinkmann]

At Thu, 29 Apr 2004 12:32:35 +0300,
Ognyan Kulev wrote:
> The following shell commands (that end up using dir_rename) give other 
> errors, but C program that uses ANSI function rename() gives EINVAL:
> 
> mv x ""                               here "" is recognized as "."
>                               and mv complains
> mv "" x                               here stat("") gives ENOENT
>                               and we don't reach dir_rename
> 
> I would like to make a patch.  But first, what are the sensible errors? 
>   Here is what I think:
> 
> dir_link("x", "") returns EINVAL
> dir_unlink("") returns ENOENT
> dir_mkdir("") returns EINVAL
> dir_rmdir("") returns ENOENT
> dir_rename("x", "") returns EINVAL
> dir_rename("", "x") returns ENOENT
> 
> mv x "" should give EINVAL, I think.  I suppose this is for the 
> coreutils developers.

You must be careful here.  The main thing that matters for us is the
POSIX interface here.  The coreutils already behave correctly, unless
there is a bug that also shows on other POSIX systems.  The dir_* are
not specified, but we can specify them.  So, we can decide if we want
to use EINVAL or ENOENT in them.  I think that there is a consistent
pattern to make them behave like the equivalent POSIX functions, but I
am not sure it is completely followed.

In any case, how rename(), unlink() etc should behave is defined by
POSIX.  I only checked unlink(), mkdir() and rename() (not rmdir and
link), and for those ENOENT is required.  You may want to check the
others.

Thanks,
Marcus