l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On PATH_MAX


From: Marcus Brinkmann
Subject: Re: On PATH_MAX
Date: Fri, 04 Nov 2005 08:00:05 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Thu, 03 Nov 2005 20:18:23 +0100,
Alfred M Szmidt wrote:
> 
>    [...] A reasonable limit is necessary.
> 
> Being _ABLE_ to set a limit is necessary.  But setting a globally
> static limit like PATH_MAX is not that solution,

It's impossible to impose a global static limit in a multi-server system.

What you mean is if a limit should be defined in glibc or not.  That's
quite a different question.  The answer might be yes even if the
system supports arbitrary lengths, for example for backwards
compatibility with programs which can only handle path lengths of a
small maximum size.

> if you increase
> PATH_MAX then you will need to recompile the whole system, and one
> program might not work on a different version of the system; this
> won't happen if you just allocate the memory for the filename.

This is completely wrong (and I made the same wrong statement before).
First, you only need to recompile the programs using PATH_MAX.  A
simple heuristic would be to grep the code for PATH_MAX.  Debian has a
tool lintian, which continously runs checks like this on the whole
source code tree of the Debian system.  It could easily produce a list
of candidates.

If you _don't_ set PATH_MAX, a program that does depend on PATH_MAX
simply won't compile in the first place, so you have to adapt it
manually before you can even compile it the first time.

Some programs use PATH_MAX even if it is not defined.  They will
simply define it to some arbitrary value, because they don't want to
support longer filenames.

I conclude that setting a global PATH_MAX is in general less trouble
than not setting it.  It's very easy to recompile even a thousand
packages.  Doesn't even take any brains.  The process today is
completely automatic.  While changing all programs to not use a static
limit is in general impossible, and not even desirable.

You may still not want to not define PATH_MAX, but not because it is
easier, but because it forces you to do more work and fix a lot of
applications and send in upstream patches which are subsequently
rejected.

As I said before, even if you define PATH_MAX in glibc, you can
_still_ support longer filenames in the filesystem _and_ applications.

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]