Od: "René Scharfe" <l.s.r@xxxxxx>
Do: "Stefan Beller" <sbeller@xxxxxxxxxx>;
Wysłane: 22:08 Piątek 2017-03-17
Temat: Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |
>
>> Am 17.03.2017 um 20:45 schrieb Stefan Beller:
>> On Fri, Mar 17, 2017 at 12:34 PM, René Scharfe 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
>>>>> 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.").
>
> I'm only interested in FreeBSD for now, as that's the platform Zenobiusz
> reported the issue on and I haven't been able to reproduce it, so this
> is still a bit exploratory, but hopefully getting closer. This
> extension is used in the first version of pwd(1) in FreeBSD's repo,
> comitted 1994-05-26, so it was supported there basically forever.
>
> The oldest version I found that's using the extention is NetBSD's
> pwd(1), which was committed 1993-03-21 and carries a SCCS timestamp of
> 1991-02-20. Visual Studio .NET 2003 supports it as well.
>
>> 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?
>
> Reducing the use of absolute paths may be a good idea in general, but
> that would probably require major changes. And Windows doesn't seem to
> offer fchdir() at all; I don't know if it has an equivalent function
> that could be used to build a replacement.
>
> René
>
>
I think I found a way to reproduce this error.
I installed FreeBSD 10.3 under qemu with zfs partitioning.
Test program did not report any access errors.
Then I did chmod 711 /usr/home
Now program started reporting permission denied errors just like this:
$ ./a.out
len = 0, errno = 22, Invalid argument
len = 1, errno = 34, Result too large
len = 2, errno = 13, Permission denied
len = 20, errno = 0, No error: 0