patchabspath: increase array size of cwd variable to PATH_MAX

From: Hui Wang <Hui.Wang@windriver.com>

If the name length of working dir exceeds 1024 characters, neither git
clone nor git init can succeed under the working dir.
E.G. %>for ((i=1;i<300;i++));do mkdir 1234567890;cd 1234567890;done
     %>git clone ~/git
     fatal: Could not get current working directory: Numerical result
     out of range

This is because both git clone and git init will call abspath.c:real_path(), in the real_path(), it will call getcwd() to get and save current working dir, here we passed a 1024 char size array to the parameter, if the name length of current working dir exceeds 1024, this function will fail.

The purpose of calling getcwd() is to save current working dir, then before the real_path() return, restore to the saved dir. We should use PATH_MAX instead of 1024 for the array size.

Signed-off-by: Hui Wang <Hui.Wang@windriver.com>
---
 abspath.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Wang Hui <Hui.Wang@windriver.com> writes:

Thanks.

This does not make things worse but in the longer term we should move away from using PATH_MAX in general.

Junio C Hamano wrote:

Hmm, the subject line says "... increase array size ...", but that is not necessarily what this patch is doing! :-D

Yes, on some platforms PATH_MAX will be larger than 1024 (e.g. 4096 on Linux), but that is not even true of all POSIX systems. POSIX defines the *minimum* value of PATH_MAX that systems must support (as #define _POSIX_PATH_MAX) of 255. [it also requires that POSIX conforming applications must not *require* a value larger than 255].

However, we don't have to look too far to find systems with much smaller values. On Cygwin, for example:

    $ cat -n junk.c
         1  #include <stdio.h>
         2  #include <limits.h>
         3
         4  int main(int argc, char *argv[])
         5  {
         6          printf("PATH_MAX is %d\n", PATH_MAX);
         7          return 0;
         8  }
    $ gcc -o junk junk.c
    $ ./junk
    $ PATH_MAX is 260
    $ 

On MinGW the answer is 259.

So, I certainly agree that moving away from PATH_MAX is a good idea, but I'm not sure I agree that this patch "does not make things worse" ... (I haven't given it *any* thought!).

[Also, note commits f66cf96, fd55a19, 620e2bb, etc...]

ATB, Ramsay Jones

Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:

True; will revert it out of 'next'.

Thanks for noticing.

Junio C Hamano wrote:

Hi Junio and Ramsay,

In fact, i found lots of similar usage in the git source code. E.G.

in the dir.c, int is_inside_dir(const char *dir) { char cwd[PATH_MAX]; if (!dir) return 0; if (!getcwd(cwd, sizeof(cwd))) die_errno("can't find the current directory"); return dir_inside_of(cwd, dir) >= 0; }

Since this implementation is not cross-OS safe, Could we use below solution?

step1, add a new function xgetcwd() to wrapper getcwd() like this: char *xgetcwd(void) { size_t size = 100;

while (1) { char *buffer = (char *) xmalloc (size); if (getcwd (buffer, size) == buffer) return buffer; free (buffer); if (errno != ERANGE) return 0; size *= 2; } }

step2, use xgetcwd to replace all getcwd occurrence in the git source code.

This will add a little bit overhead to the git, but it is cross-OS safe.

Ramsay Jones wrote:

Hi Ramsay,

Do you mean the PATH_MAX of a system should not be the limitation for the git. That is to say, the git can handle the path which has name longer than PATH_MAX? If it is, my patch is not needed here. :-)