[Top][All Lists]

[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: Jérémie Koenig
Subject: Re: glibc: changing file_name_split()'s interface slightly to fix the "/" case
Date: Sun, 13 Jun 2010 14:22:41 +0200

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>

reply via email to

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