From: Carlos Martín Nieto <cmn@elego.de>
Date: Mon, 21 Mar 2011 09:47:52 GMT
Subject: Re: PATH_MAX (Re: [PATCH] system_path: use a static buffer)
Message-ID: <1300700875.2583.8.camel@bee.lab.cmartin.tk>
In-Reply-To: <20110318113818.GA6049@elie>

On vie, 2011-03-18 at 06:38 -0500, Jonathan Nieder wrote:
> 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