Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

> On Fri, Mar 17, 2017 at 12:34 PM, René Scharfe <l.s.r@web.de> wrote:
>> Am 15.03.2017 um 22:30 schrieb René Scharfe:
>>> Am 15.03.2017 um 10:44 schrieb Zenobiusz Kunegunda:
>>>> $ git bisect bad
>>>> 7333ed1788b4f2b162a35003044d77a716732a1f is the first bad commit
>>>> commit 7333ed1788b4f2b162a35003044d77a716732a1f
>>>> Author: René Scharfe <l.s.r@web.de>
>>>> Date:   Mon Jul 28 20:26:40 2014 +0200
>>>>
>>>>     setup: convert setup_git_directory_gently_1 et al. to strbuf
>>>
>>> That's what I half-suspected, and I think by now I got an idea.  Here's
>>> a test program:
>>
>> And here's a patch for letting strbuf_getcwd() use the same getcwd(3)
>> extension that pwd(1) uses.  It avoids the need to guess the path's
>> length and thus reduces the chance of stumbling over strange error
>> codes.  I wonder if it helps in your case.
>>
>> René
>>
>> ---
>>  strbuf.c | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/strbuf.c b/strbuf.c
>> index ace58e7367..4c02801edd 100644
>> --- a/strbuf.c
>> +++ b/strbuf.c
>> @@ -442,6 +442,14 @@ int strbuf_getcwd(struct strbuf *sb)
>>  {
>>         size_t oldalloc = sb->alloc;
>>         size_t guessed_len = 128;
>> +       char *cwd;
>> +
>> +       cwd = getcwd(NULL, 0);
>
> from my local man pages:
>
>   As  an extension to the POSIX.1-2001 standard, Linux (libc4, libc5,
> glibc) getcwd()
>   allocates the buffer dynamically using malloc(3) if buf is NULL.  In
> this case, the
>   allocated buffer has the length size unless size is zero, when buf
> is allocated as big
>   as necessary.  The caller should free(3) the returned buffer.
>
> This sounds specific to Linux (though I am reading Linux man pages,
> which claim this; Also it seems I might have misread it as it also states
> "The pathname is returned as the function result and via the
> argument buf, if present.").

> Looking further:
>
>   These functions are often used to save the location of the current
>   working directory for the purpose of returning to it later.  Opening the
>   current directory (".")  and  calling  fchdir(2)  to return is
> usually a faster
>   and more reliable alternative when sufficiently many file descriptors are
>   available, especially on platforms other than Linux.
>
> Not sure if that opens another door here?