RE: On PATH_MAX

[Christopher Nelson]

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

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.

-={C}=-