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

[Roland McGrath]

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

Oh, I didn't read it closely.  Yeah, don't do that.

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

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

Actually, you're trying to access the root, and do an RPC on it with no
name.  It's just a matter of perspective.

> Which is the rationale behind my "." thing, although admittedly that
> would mean the dot link itself rather than the node being contacted.

At least in my day, that was an actual distinction we cared about.

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

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

I think it's fairly clear that mkdir on / should return EEXIST.

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

Yes.


Thanks,
Roland