[Top][All Lists]
[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
- On PATH_MAX, Ludovic Courtès, 2005/11/02
- RE: On PATH_MAX, Christopher Nelson, 2005/11/03
- Re: On PATH_MAX, Marcus Brinkmann, 2005/11/03
- Re: On PATH_MAX, Alfred M\. Szmidt, 2005/11/03
- Re: On PATH_MAX,
Marcus Brinkmann <=
- Re: On PATH_MAX, Alfred M\. Szmidt, 2005/11/04
- Re: On PATH_MAX, Jonathan S. Shapiro, 2005/11/04
- Re: On PATH_MAX, Alfred M\. Szmidt, 2005/11/04
- Message not available
- Re: On PATH_MAX, Jonathan S. Shapiro, 2005/11/04
- Re: On PATH_MAX, Alfred M\. Szmidt, 2005/11/04
- Re: On PATH_MAX, Michal Suchanek, 2005/11/04
- Re: On PATH_MAX, Michal Suchanek, 2005/11/04
RE: On PATH_MAX, Christopher Nelson, 2005/11/03
RE: On PATH_MAX, Christopher Nelson, 2005/11/03
RE: On PATH_MAX, Christopher Nelson, 2005/11/03