On PATH_MAX

[Michal Suchanek]

On 11/8/05, Christopher Nelson <address@hidden> wrote:
> > > Assuming that the server's service requires the filename
> > (perhaps it
> > > is a filesystem server, or perhaps it is a photo album
> > server... Both
> > > services are equivalent in this example.) then of course it has to
> > > process the filename.  At some point someone has to
> > actually process
> > > the filename.  Otherwise there's no point in having it.
> >
> > The name is for you to know what is in the file. The server
> > does not need the name to know that.
>
> Eventually, some server needs to know the filename.  How else is the
> file mapped to its content?  If you are using a hierarchical filesytem,
> *someone* has to walk the filename to get to the data.  If you are using
> an object-based, single-level store, you *still* have to identify some
> objects with human friendly names.  That is symbolically analagous to a
> filename.  So while not *everyone* needs to know it, and some point some
> server has to know it.

You can just read the symbolical name and present it to the user, or
search for an object with the name requested by the user.
Still it can be your application (or some code in libc) that resolves
the human friendly names, and the server and software that does not
want to deal with the complexity can avoid it.
Certainly some code for finding the requested name must exist. But it
can be place in several places.
For one, in the current Hurd the translator only knows how to resolve
names in its own namespace. If another translators are attached at
some points in the path, the lookup is iterated over these translators
in libc. If libc can work with this, it can work with inodes numbers,
or whatever else is short enough.

Thanks

Michal