[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>
http://jk.fr.eu.org/