bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ognyan Kulev
Subject: Re: [Fwd: [bug #6047] rm -f "" prints diagnostic message under the Hurd]
Date: Thu, 29 Apr 2004 14:26:21 +0300
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-0.backports.org.1

Here "POSIX" means "The Single UNIX Specification Version 3".

Marcus Brinkmann wrote:
At Thu, 29 Apr 2004 12:32:35 +0300,
Ognyan Kulev wrote:
dir_link("x", "") returns EINVAL

link(path1, path2) contains the following text:

[ENOENT]
A component of either path prefix does not exist; the file named by path1 does not exist; or path1 or path2 points to an empty string.

So dir_link("x","") should return ENOENT. (Here is implied that Hurd RPCs should follow POSIX semantics. Another solution is to change glibc and not change diskfs.)

dir_unlink("") returns ENOENT

unlink(path):

[ENOENT]
A component of path does not name an existing file or path is an empty string.

dir_mkdir("") returns EINVAL

mkdir(path):

[ENOENT]
A component of the path prefix specified by path does not name an existing directory or path is an empty string.

dir_rmdir("") returns ENOENT

[ENOENT]
A component of path does not name an existing file, or the path argument names a nonexistent directory or points to an empty string.

dir_rename("x", "") returns EINVAL
dir_rename("", "x") returns ENOENT

rename(old,new):

[ENOENT]
[CX] The link named by old does not name an existing file, or either old or new points to an empty string.


open(path,oflag):

[ENOENT]
O_CREAT is not set and the named file does not exist; or O_CREAT is set and either the path prefix does not exist or the path argument points to an empty string.

I think that touch "" returns EINVAL under the Hurd, but I'm lazy to check it right now.

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.

From the excerpts above, it looks like POSIX system interfaces always return ENOENT when some pathname is empty string. Here is the description of ENOENT in error numbers:

[ENOENT]
No such file or directory. A component of a specified pathname does not exist, or the pathname is an empty string.

Again, the easiest is to make diskfs_lookup return ENOENT when empty string is given. Or we can change dir_* functions, which is not hard. glibc can be changed too, but I suppose we want Hurd RPCs to have the POSIX behaviour.

Regards,
ogi




reply via email to

[Prev in Thread] Current Thread [Next in Thread]