From: René Scharfe Date: Fri, 17 Mar 2017 21:07:18 GMT Subject: Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 | Message-ID: <250f6b35-03c3-1fa8-8b6b-dfdc42660d8c@web.de> In-Reply-To: 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é