Re: On PATH_MAX

[Bas Wijnen]

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.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature