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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html