Re: [PATCH] abspath.c: use PATH_MAX in real_path_internal()

[Karsten Blees <karsten.blees@gmail.com>]

Am 18.07.2014 13:32, schrieb René Scharfe:
> Am 18.07.2014 01:03, schrieb Karsten Blees:
>> Am 17.07.2014 19:05, schrieb René Scharfe:
>>> Am 17.07.2014 14:45, schrieb Nguyễn Thái Ngọc Duy:
>> [...]
>>> "These routines have traditionally been used by programs to save the
>>> name of a working directory for the purpose of returning to it. A much
>>> faster and less error-prone method of accomplishing this is to open the
>>> current directory (.) and use the fchdir(2) function to return."
>>>
>>
>> fchdir() is part of the POSIX-XSI extension, as is realpath(). So why not
>> use realpath() directly (which would also be thread-safe)?
> 
> That's a good question; thanks for stepping back and looking at the bigger picture.  If there is widespread OS support for a functionality then we should use it and just provide a compatibility implementation for those platforms lacking it.  The downside is that compat code gets less testing.
> 

I just noticed that in contrast to the POSIX realpath(), our real_path() doesn't require the last path component to exist. I don't know if this property is required by the calling code, though.

> Seeing that readlink()

You mean realpath()? We don't have a stub for that yet.

> is left as a stub in compat/mingw.h that only errors out, would the equivalent function on Windows be PathCanonicalize (http://msdn.microsoft.com/en-us/library/windows/desktop/bb773569%28v=vs.85%29.aspx)?
> 

PathCanonicalize() doesn't return an absolute path, the realpath() equivalent would be GetFullPathName() (doesn't resolve symlinks) or GetFinalPathNameByHandle() (requires Vista, resolves symlinks, requires the path to exist).

>> For non-XSI-compliant platforms, we could keep the current implementation.
> 
> OK, so realpath() for Linux and the BSDs, mingw_realpath() wrapping PathCanonicalize() for Windows and the current code for the rest?
> 
>> Or re-implement a thread-safe version, e.g. applying resolve_symlink() from
>> lockfile.c to all path components.
> 
> Thread safety sounds good.  We'd also need something like normalize_path_copy() but without the conversion of backslashes to slashes, in order to get rid of "." and ".." path components and something like absolute_path() that doesn't die on error, no?
> 

Windows can handle forward slashes, so normalize_path_copy works just fine.

>> If I may bother you with the Windows point of view:
>>
>> There is no fchdir(), and I'm pretty sure open(".") won't work either.
> 
> On Windows, there *is* an absolute path length limit of 260 in the normal case and a bit more than 32000 for some functions using the \\?\ namespace. So one could get away with using a constant-sized buffer for a "remember the place and return later" function here.
> 

The current directory is pretty much the only exception to the \\?\ trick [1]. So a fixed buffer for getcwd() would actually be fine on Windows (although it would have to be 3 * PATH_MAX, as PATH_MAX wide chars will convert to at most 3 * PATH_MAX UTF-8 chars).

However, a POSIX conformant getcwd must fail with ERANGE if the buffer is too small. So a better alternative would be to add a strbuf_getcwd() that works similar to strbuf_readlink() (i.e. resize the buffer until its large enough).

Side note: the 'hard' 260 limit for the current directory also means that as long as we *simulate* realpath() via chdir()/getcwd(), long paths [1] don't work here.

> Also, _getcwd can be asked to allocate an appropriately-sized buffer for use, like GNU's get_current_dir_name, by specifying NULL as its first parameter (http://msdn.microsoft.com/en-us/library/sf98bd4y.aspx).
> 

We use nedmalloc in the Windows builds, so unfortuately we cannot free memory allocated by MSVCRT.dll.


[1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa365530%28v=vs.85%29.aspx
[2] https://github.com/msysgit/git/commit/84393750