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

[Jérémie Koenig]

On Sun, Jun 13, 2010 at 1:17 PM, Roland McGrath <roland@frob.com> wrote:
>> Is the empty string supposed to refer to the node itself somehow?
>
> It does.  To look up "." you need search (execute) permission on the
> directory.  To look up "" it just has to actually be a directory port.
> At least, that's the way I remember it from the previous millenium.

Okay, thanks, I didn't know that. I've checked fs.defs and the
behavior you describe is documented for dir_lookup(). (for what it's
worth it says that the null string should be supported on
non-directory files too).

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).

> (...)
>> I'm thinking more and more that it's the libc's job to handle this
>> case, rather than passing the ambiguity on to the file system server.
>
> I don't follow.

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.
-- 
Jérémie Koenig <jk@jk.fr.eu.org>
http://jk.fr.eu.org/