Re: PATH_MAX (Re: [PATCH] system_path: use a static buffer)
On vie, 2011-03-18 at 06:38 -0500, Jonathan Nieder wrote:
Show 15 quoted lines
> Hi,
>
> Nguyen Thai Ngoc Duy wrote:
>
> > It was pointed out elsewhere [1] that PATH_MAX only specifies max
> > length of a path element, not full path. I think we'd need to stay
> > away from preallocated PATH_MAX-sized arrays.
>
> No, PATH_MAX is actually the maximum length of a path, and when you
> use, say, open(2), it will fail if your path is longer than that. The
> maximum length of a path component on most filesytems is 255 or 256;
> PATH_MAX on Linux is 4096.
>
> It is indeed possible to have paths with length longer than that. The
> way to support that is to use relative paths wherever possible, which
So what PATH_MAX describes is the maximum length of a string
representing a path, but not necessarily the length of the path itself.
> does sound to me like an interesting long-term goal (mostly because I
> suspect the result would be easier to read and, especially, to reason
> about with respect to race conditions).
There is also the following effect with git
carlos@bee:~/apps$ mkdir one
carlos@bee:~/apps$ ln -s one two
carlos@bee:~/apps$ ln -s two three
carlos@bee:~/apps$ cd three
carlos@bee:~/apps/three$ git init
Initialized empty Git repository in /home/carlos/apps/one/.git/
which is at best a bit annoying. Many instances of real_path (formerly
make_absolute_path) could be skipped and is_inside_dir could do the
transformation to physical path if it needs to.
There may be a few edge cases, but most of the transformation should be
fairly straightforward (he says as he steps off the cliff...)
cmn