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

[Jérémie Koenig]

On Sun, Jun 13, 2010 at 11:51 AM, Roland McGrath <roland@frob.com> wrote:
>> You mean directory_name_split("/") should return (<root port>, "") ?
>
> I do.  "This is the same as file_name_split, but ignores trailing slashes."
> (...)

Note that my patch changes both of them to return (<CRD>, "."), and
alters the documentation accordingly, though my post was unclear about
this (sorry).

>> This makes mkdir(), for instance, fail with EINVAL as well.
>
> Well, what should it do?  I suppose it should fail with EEXIST instead.
> That seems like a filesystem server problem, not a client-side problem.

Is the empty string supposed to refer to the node itself somehow?

>> Should it be handled on a case-by-case basis in the individual POSIX
>> calls (mkdir, rmdir, link, unlink, ...) ?
>
> No, that's what the *_split calls are for.
>
> For "/", all these mean an RPC made on the root directory port itself.

What's unclear is that we're trying to access the root's "parent
directory" and do an RPC on it with the root's "base name". Which is
the rationale behind my "." thing, although admittedly that would mean
the dot link itself rather than the node being contacted.

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.

> What could mkdir, rmdir, or unlink possibly mean for the root of a tree?

Not much of course, but we should try to return a conforming error in
this case, though arguably POSIX is not very clear on what should
happen.

For what it's worth, what got me interested in this is the busybox
implementation of 'mkdir -p' relying on mkdir("/") returning EEXIST.
I'm not sure many such use cases exist.

> For link, we're talking about the target, i.e. "ln something /", so the
> question is the same.

I guess EEXIST should also be returned in this case.

Anyway thanks for taking the time to consider this,
-- 
Jérémie Koenig <jk@jk.fr.eu.org>
http://jk.fr.eu.org/