bug-hurd
[Top][All Lists]
Advanced

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

Re: glibc: changing file_name_split()'s interface slightly to fix the "/


From: Roland McGrath
Subject: Re: glibc: changing file_name_split()'s interface slightly to fix the "/" case
Date: Sun, 13 Jun 2010 13:04:41 -0700 (PDT)

> However there's nothing such for the calls manipulating the links of a
> directory such as dir_mkdir(), dir_rmdir(), dir_unlink() and so on.
> These apparently return EINVAL on an empty string (or at least my
> /hurd/ext2fs does).

Well, as we've been noting here, there is not really any sensical meaning
to "mkdir yourself", etc.

> I mean there's no link to be manipulated here, which is what these RPC
> calls are about; and you're right that the distinction between links
> and nodes is important. Considering this I'm not sure we should
> require them to handle the empty string case.

Right.  That does make sense for the RPCs themselves.  OTOH for the libc
calls we do want the other errors instead of EINVAL (which IMHO here is
nearly as bizarre to a user as EGRATUITOUS would be), and adding special
cases just feels wrong.  (To be pedantic, I don't think this is a POSIX
conformance issue.  All calls can return other errors for other cases not
mentioned in the spec--it's just that they must return the specified error
for the cases that are specified.  For these cases, we can say that the
case is not "it already exists" or so forth but is "that doesn't make sense
on /".  But, that said, I think as a quality of implementation issue EINVAL
is a poor choice for these cases.)

On Linux, the errors are:

mkdir, mknod, link - EEXIST
unlink - EISDIR
rmdir - EBUSY

It does these checks before permission checks, so you get those errors
instead of EACCES or EPERM even if you wouldn't be allowed to do any of
those things to the / node.  For the Hurd, that means we could diagnose
those without actually doing any RPC.  Those error codes make sense except
possibly for the EBUSY case.


Thanks,
Roland



reply via email to

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