git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Stefan Beller <sbeller@google.com>
Date
Mar 17, 2017, 19:45 UTC
Message-ID
<CAGZ79kbpPBN21mbN2F20ikr6dXrKEcY=msqymaG8TOujeQF0jw@mail.gmail.com>
In-Reply-To
<f6588ace-eecc-118d-ef26-70bc21dcc4d4@web.de>
On Fri, Mar 17, 2017 at 12:34 PM, René Scharfe <l.s.r@web.de> wrote:
Show 35 quoted lines
> 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?

Thanks, Stefan

Previous: René ScharfeNext: René Scharfe
Message 15 of 23 in “fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |”
  1. Zenobiusz KunegundaMar 6, 2017
  2. René ScharfeMar 8, 2017
  3. Zenobiusz KunegundaMar 9, 2017
  4. René ScharfeMar 11, 2017
  5. Zenobiusz KunegundaMar 13, 2017
  6. René ScharfeMar 13, 2017
  7. Zenobiusz KunegundaMar 14, 2017
  8. Zenobiusz KunegundaMar 13, 2017
  9. René ScharfeMar 13, 2017
  10. Zenobiusz KunegundaMar 14, 2017
  11. René ScharfeMar 14, 2017
  12. Zenobiusz KunegundaMar 15, 2017
  13. René ScharfeMar 15, 2017
  14. René ScharfeMar 17, 2017
  15. Stefan BellerMar 17, 2017
  16. René ScharfeMar 17, 2017
  17. Jeff KingMar 17, 2017
  18. René ScharfeMar 17, 2017
  19. Zenobiusz KunegundaMar 21, 2017
  20. René ScharfeMar 21, 2017
  21. Zenobiusz KunegundaMar 22, 2017
  22. Zenobiusz KunegundaMar 21, 2017
  23. Zenobiusz KunegundaMar 9, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.