Re: On PATH_MAX

[Michal Suchanek]

On 11/8/05, Bas Wijnen <address@hidden> wrote:
> On Mon, Nov 07, 2005 at 09:57:49AM -0700, Christopher Nelson wrote:
> > > On Mon, 2005-11-07 at 09:32 -0700, Christopher Nelson wrote:
> > > It is possible to design protocols that are flawed in the way
> > > that you describe, but they are self-evidently broken.
> >
> > Yes, this is my point exactly.  Requiring support for arbitrary sized
> > string transfers is a broken mechanism.  I don't feel that it's a good
> > idea to expect a server to simply accept whatever you throw at it.  Up
> > to and including bazillion-character-long paths.  The example was
> > designed to highlight that, and it seems to have successfully done so.
>
> Not exactly.  If a server wants to support arbitrary long paths, it's not
> going to map the whole thing into its address space.  It'll accept a container
> capability and map parts of it in, unmapping other parts of it.
>
> The problem that remains is that the operation can take very long.  If you
> have a 4GB filename (or the maximum 64 bit value), the server will have a lot
> of work checking it.  Then again, it's doing that on your provided scheduling
> time, so that should be no problem, as long as other requests are not delayed
> by it.

And why does the server need to check the filename? In what way?

Thanks

Michal

--
             Support the freedom of music!
Maybe it's a weird genre  ..  but weird is *not* illegal.
Maybe next time they will send a special forces commando
to your picnic .. because they think you are weird.
 www.music-versus-guns.org  http://en.policejnistat.cz