[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: glibc: changing file_name_split()'s interface slightly to fix the "/
Re: glibc: changing file_name_split()'s interface slightly to fix the "/" case
Sun, 13 Jun 2010 14:22:41 +0200
On Sun, Jun 13, 2010 at 1:17 PM, Roland McGrath <email@example.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
>> 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 <firstname.lastname@example.org>