> 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
