RE: On PATH_MAX

[Christopher Nelson]

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

What mechanism allows it to map *parts* of a single transfer in?
 
> 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.

Sure, except that while it's working on YOUR request, it's not
processing anyone else's request.

-={C}=-