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

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

[Zenobiusz Kunegunda]

OS: FreeBSD 10.3-STABLE

Story:
I was trying to install openproject using this manual
https://www.openproject.org/open-source/download/manual-installation-guide/

Everything was fine till command
$ bundle install --deployment --without postgres sqlite development test therubyracer docker

works witg git version: 
1.9.5 ( branch from repo )
does not work with git version: 
2.10 ( branch from from repo ) 
2.11 ( both from FreeBSD and from git repository) 
2.12 ( branch from repo )

On another server that passed but there was npm problem.

This is error for 
$ bundle install --deployment --without postgres sqlite development test therubyracer docker

=== output begin ===
Error message (this is from git 2.11; 2.10 and 2.12 report same error):
$ bundle install --deployment --without postgres sqlite development test therubyracer docker 
The git source `git://github.com/oliverguenther/omniauth.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/finnlabs/awesome_nested_set.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/why-el/svg-graph.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/opf/rails-angular-xss.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/goodwill/capybara-select2.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/omniauth/omniauth-saml.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
Fetching gem metadata from https://rubygems.org/.......
Fetching version metadata from https://rubygems.org/..
Fetching dependency metadata from https://rubygems.org/.
fatal: Could not get current working directory: Permission denied

Retrying `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"` due to error (2/4): Bundler::Source::Git::GitCommandError Git error: command `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"` in directory /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2 has failed.
If this error persists you could try removing the cache directory '/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7'fatal: Could not get current working directory: Permission denied

Retrying `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"` due to error (3/4): Bundler::Source::Git::GitCommandError Git error: command `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"` in directory /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2 has failed.
If this error persists you could try removing the cache directory '/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7'fatal: Could not get current working directory: Permission denied

Retrying `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"` due to error (4/4): Bundler::Source::Git::GitCommandError Git error: command `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"` in directory /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2 has failed.
If this error persists you could try removing the cache directory '/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7'fatal: Could not get current working directory: Permission denied

Git error: command `git fetch --force --quiet --tags
"/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"`
in directory /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2 has
failed.
If this error persists you could try removing the cache directory
'/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7'
=== output end ===

removing cache directory did not help

My own debuging( git 2.12 ):

diff --git a/Makefile b/Makefile
index 9ec6065cc..391d765e7 100644
--- a/Makefile
+++ b/Makefile
@@ -405,7 +405,7 @@ DEVELOPER_CFLAGS = -Werror \
        -Wstrict-prototypes \
        -Wunused \
        -Wvla
-LDFLAGS =
+LDFLAGS = -lexecinfo
 ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
 ALL_LDFLAGS = $(LDFLAGS)
 STRIP ?= strip
@@ -1437,6 +1437,7 @@ ifdef RUNTIME_PREFIX
        COMPAT_CFLAGS += -DRUNTIME_PREFIX
 endif
 
+#define NO_PTHREADS 1
 ifdef NO_PTHREADS
        BASIC_CFLAGS += -DNO_PTHREADS
 else
diff --git a/setup.c b/setup.c
index 967f289f1..0879b755f 100644
--- a/setup.c
+++ b/setup.c
@@ -848,6 +848,7 @@ static const char *setup_git_directory_gently_1(int *nongit_ok)
        if (nongit_ok)
                *nongit_ok = 0;
 
+       fprintf(stderr,"*** DBG ***\n");
        if (strbuf_getcwd(&cwd))
                die_errno(_("Unable to read current working directory"));
        offset = cwd.len;
diff --git a/strbuf.c b/strbuf.c
index 8fec6579f..bd598e440 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -442,13 +442,25 @@ int strbuf_getcwd(struct strbuf *sb)
 {
        size_t oldalloc = sb->alloc;
        size_t guessed_len = 128;
+char *USER_diag;
+int USER_i=0;
+
+       struct timespec spec;
+
+       clock_gettime(CLOCK_REALTIME, &spec);
+
+
+       fprintf(stderr,"PID:%d DBG[strbuf_getcwd()]\n",getpid());
 
        for (;; guessed_len *= 2) {
                strbuf_grow(sb, guessed_len);
-               if (getcwd(sb->buf, sb->alloc)) {
+               fprintf(stderr,"PID:%d TIME:%ld DBG<BEFORE getcwd()> sb->buf[%s]length(%lu) sb->alloc[%lu]\n",getpid(),spec.tv_nsec,sb->buf,strlen(sb->buf),sb->alloc);
...skipping...
diff --git a/Makefile b/Makefile
diff --git a/Makefile b/Makefile
index 9ec6065cc..391d765e7 100644
--- a/Makefile
+++ b/Makefile
@@ -405,7 +405,7 @@ DEVELOPER_CFLAGS = -Werror \
        -Wstrict-prototypes \
        -Wunused \
        -Wvla
-LDFLAGS =
+LDFLAGS = -lexecinfo
 ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
 ALL_LDFLAGS = $(LDFLAGS)
 STRIP ?= strip
@@ -1437,6 +1437,7 @@ ifdef RUNTIME_PREFIX
        COMPAT_CFLAGS += -DRUNTIME_PREFIX
 endif
 
+#define NO_PTHREADS 1
 ifdef NO_PTHREADS
        BASIC_CFLAGS += -DNO_PTHREADS
 else
diff --git a/setup.c b/setup.c
index 967f289f1..0879b755f 100644
--- a/setup.c
+++ b/setup.c
@@ -848,6 +848,7 @@ static const char *setup_git_directory_gently_1(int *nongit_ok)
        if (nongit_ok)
                *nongit_ok = 0;
 
+       fprintf(stderr,"*** DBG ***\n");
        if (strbuf_getcwd(&cwd))
                die_errno(_("Unable to read current working directory"));
        offset = cwd.len;
diff --git a/strbuf.c b/strbuf.c
index 8fec6579f..bd598e440 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -442,13 +442,25 @@ int strbuf_getcwd(struct strbuf *sb)
 {
        size_t oldalloc = sb->alloc;
        size_t guessed_len = 128;
+char *USER_diag;
+int USER_i=0;
+
+       struct timespec spec;
+
+       clock_gettime(CLOCK_REALTIME, &spec);
+
+
+       fprintf(stderr,"PID:%d DBG[strbuf_getcwd()]\n",getpid());
 
        for (;; guessed_len *= 2) {
                strbuf_grow(sb, guessed_len);
-               if (getcwd(sb->buf, sb->alloc)) {
+               fprintf(stderr,"PID:%d TIME:%ld DBG<BEFORE getcwd()> sb->buf[%s]length(%lu) sb->alloc[%lu]\n",getpid(),spec.tv_nsec,sb->buf,strlen(sb->buf),sb->alloc);
+               if (USER_diag=getcwd(sb->buf, sb->alloc)) {
+                       USER_i++;
+                       fprintf(stderr,"PID:%d getcwd success? Result [%s] loop step number %d\n",getpid(),USER_diag,USER_i);
                        strbuf_setlen(sb, strlen(sb->buf));
                        return 0;
-               }
+               }else{fprintf(stderr,"PID: %d >>DBG<< not expected value!\n",getpid());}
                if (errno != ERANGE)
                        break;
        }
diff --git a/usage.c b/usage.c
index ad6d2910f..989403829 100644
--- a/usage.c
+++ b/usage.c
@@ -6,6 +6,8 @@
 #include "git-compat-util.h"
 #include "cache.h"
 
+#include <execinfo.h>
+
 static FILE *error_handle;
 
 void vreportf(const char *prefix, const char *err, va_list params)
@@ -30,7 +32,21 @@ static NORETURN void usage_builtin(const char *err, va_list params)
 
 static NORETURN void die_builtin(const char *err, va_list params)
 {
-       vreportf("fatal: ", err, params);
+       void *btlist[30];
+       size_t size, i;
+       char **strings;
+               
+       size=backtrace(btlist,30);
+       strings=backtrace_symbols(btlist,size);
+
+       fprintf(stderr,"\n-----[DBG] PID:%d -----\n",getpid());
+         for (i = 0; i < size; i++)
+                      fprintf (stderr,"%s\n", strings[i]);
+
+           free (strings);
+
+       vreportf("DBG fatal: ", err, params);
+       fprintf(stderr,"\n----------------\n");
        exit(128);
 }

After installation of altered git:

$bundle install --deployment --without postgres sqlite development test therubyracer docker 
=== DEBUG OUTPUT BEGIN ===
The git source `git://github.com/oliverguenther/omniauth.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/finnlabs/awesome_nested_set.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/why-el/svg-graph.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/opf/rails-angular-xss.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/goodwill/capybara-select2.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/omniauth/omniauth-saml.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
Fetching gem metadata from https://rubygems.org/.......
Fetching version metadata from https://rubygems.org/..
Fetching dependency metadata from https://rubygems.org/.
*** DBG ***
PID:94818 DBG[strbuf_getcwd()]
PID:94818 TIME:319762826 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94818 >>DBG<< not expected value!
PID:94818 TIME:319762826 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94818 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7] loop step number 1
PID:94818 DBG[strbuf_getcwd()]
PID:94818 TIME:323757205 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94818 >>DBG<< not expected value!
PID:94818 TIME:323757205 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94818 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7] loop step number 1
*** DBG ***
PID:94819 DBG[strbuf_getcwd()]
PID:94819 TIME:335244142 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94819 >>DBG<< not expected value!
PID:94819 TIME:335244142 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94819 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94819 DBG[strbuf_getcwd()]
PID:94819 TIME:338873233 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94819 >>DBG<< not expected value!
PID:94819 TIME:338873233 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94819 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94819 DBG[strbuf_getcwd()]
PID:94819 TIME:343362594 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94819 >>DBG<< not expected value!
PID:94819 TIME:343362594 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94819 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94820 DBG[strbuf_getcwd()]
PID:94820 TIME:353434903 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94820 >>DBG<< not expected value!
PID:94820 TIME:353434903 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94820 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7] loop step number 1
*** DBG ***
PID:94822 DBG[strbuf_getcwd()]
PID:94822 TIME:371149025 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94822 >>DBG<< not expected value!
PID:94822 TIME:371149025 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94822 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94822 DBG[strbuf_getcwd()]
PID:94822 TIME:374747601 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94822 >>DBG<< not expected value!
PID:94822 TIME:374747601 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94822 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94822 DBG[strbuf_getcwd()]
PID:94822 TIME:378719206 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94822 >>DBG<< not expected value!
PID:94822 TIME:378719206 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94822 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94823 DBG[strbuf_getcwd()]
PID:94823 TIME:389423303 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94823 >>DBG<< not expected value!
PID:94823 TIME:389423303 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94823 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94823 DBG[strbuf_getcwd()]
PID:94823 TIME:392901921 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94823 >>DBG<< not expected value!
PID:94823 TIME:392901921 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94823 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94823 DBG[strbuf_getcwd()]
PID:94823 TIME:396779140 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94823 >>DBG<< not expected value!
PID:94823 TIME:396779140 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94823 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94824 DBG[strbuf_getcwd()]
PID:94824 TIME:405767954 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94824 >>DBG<< not expected value!
PID:94824 TIME:405767954 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94824 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94824 DBG[strbuf_getcwd()]
PID:94824 TIME:409104219 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94824 >>DBG<< not expected value!
PID:94824 TIME:409104219 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94824 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94824 DBG[strbuf_getcwd()]
PID:94824 TIME:413360941 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94824 >>DBG<< not expected value!
PID:94824 TIME:413360941 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94824 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94824 DBG[strbuf_getcwd()]
PID:94824 TIME:416863094 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94824 >>DBG<< not expected value!
PID:94824 TIME:416863094 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94824 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94824 DBG[strbuf_getcwd()]
PID:94824 TIME:420124766 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94824 >>DBG<< not expected value!
PID:94824 TIME:420124766 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94824 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94824 DBG[strbuf_getcwd()]
PID:94824 TIME:425145306 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94824 >>DBG<< not expected value!
PID:94824 TIME:425145306 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94824 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94824 DBG[strbuf_getcwd()]
PID:94824 TIME:428797180 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94824 >>DBG<< not expected value!
PID:94824 TIME:428797180 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94824 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94824 DBG[strbuf_getcwd()]
PID:94824 TIME:432288523 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94824 >>DBG<< not expected value!
PID:94824 TIME:432288523 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94824 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94841 DBG[strbuf_getcwd()]
PID:94841 TIME:473033293 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94841 >>DBG<< not expected value!
PID:94841 TIME:473033293 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94841 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94841 DBG[strbuf_getcwd()]
PID:94841 TIME:476443996 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94841 >>DBG<< not expected value!
PID:94841 TIME:476443996 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94841 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94843 DBG[strbuf_getcwd()]
PID:94843 TIME:483572829 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94843 >>DBG<< not expected value!
PID:94843 TIME:483572829 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94843 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94843 DBG[strbuf_getcwd()]
PID:94843 TIME:487028828 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94843 >>DBG<< not expected value!
PID:94843 TIME:487028828 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94843 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94844 DBG[strbuf_getcwd()]
PID:94844 TIME:493903306 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94844 >>DBG<< not expected value!
PID:94844 TIME:493903306 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94844 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94844 DBG[strbuf_getcwd()]
PID:94844 TIME:497394735 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94844 >>DBG<< not expected value!
PID:94844 TIME:497394735 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94844 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94846 DBG[strbuf_getcwd()]
PID:94846 TIME:509674151 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94846 >>DBG<< not expected value!
PID:94846 TIME:509674151 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94846 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94846 DBG[strbuf_getcwd()]
PID:94846 TIME:512716769 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94846 >>DBG<< not expected value!
PID:94846 TIME:512716769 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94846 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94847 DBG[strbuf_getcwd()]
PID:94847 TIME:520195459 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94847 >>DBG<< not expected value!
PID:94847 TIME:520195459 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94847 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94847 DBG[strbuf_getcwd()]
PID:94847 TIME:523205769 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94847 >>DBG<< not expected value!
PID:94847 TIME:523205769 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94847 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94850 DBG[strbuf_getcwd()]
PID:94850 TIME:531746240 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94850 >>DBG<< not expected value!
PID:94850 TIME:531746240 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94850 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94850 DBG[strbuf_getcwd()]
PID:94850 TIME:534777909 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94850 >>DBG<< not expected value!
PID:94850 TIME:534777909 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94850 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94853 DBG[strbuf_getcwd()]
PID:94853 TIME:584052480 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94853 >>DBG<< not expected value!
PID:94853 TIME:584052480 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94853 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2] loop step number 1
PID:94853 DBG[strbuf_getcwd()]
PID:94853 TIME:587643433 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94853 >>DBG<< not expected value!
PID:94853 TIME:587643433 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94853 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2] loop step number 1
*** DBG ***
PID:94854 DBG[strbuf_getcwd()]
PID:94854 TIME:598012950 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94854 >>DBG<< not expected value!

-----[DBG] PID:94854 -----
0x550612 <die_builtin+0x32> at /home/USER/bin/git
0x5500d9 <die_errno+0xc9> at /home/USER/bin/git
0x526f67 <setup_git_directory_gently+0x677> at /home/USER/bin/git
0x405635 <handle_builtin+0x145> at /home/USER/bin/git
0x404fcd <cmd_main+0xfd> at /home/USER/bin/git
0x47f779 <main+0x69> at /home/USER/bin/git
0x404d8f <_start+0x16f> at /home/USER/bin/git
DBG fatal: Unable to read current working directory: Permission denied

----------------

Retrying `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2"` due to error (2/4): Bundler::Source::Git::GitCommandError Git error: command `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2"` in directory /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/omniauth-8385bc0da47e has failed.
If this error persists you could try removing the cache directory '/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2'*** DBG ***
PID:94855 DBG[strbuf_getcwd()]
PID:94855 TIME:617961661 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94855 >>DBG<< not expected value!

-----[DBG] PID:94855 -----
0x550612 <die_builtin+0x32> at /home/USER/bin/git
0x5500d9 <die_errno+0xc9> at /home/USER/bin/git
0x526f67 <setup_git_directory_gently+0x677> at /home/USER/bin/git
0x405635 <handle_builtin+0x145> at /home/USER/bin/git
0x404fcd <cmd_main+0xfd> at /home/USER/bin/git
0x47f779 <main+0x69> at /home/USER/bin/git
0x404d8f <_start+0x16f> at /home/USER/bin/git
DBG fatal: Unable to read current working directory: Permission denied

----------------

Retrying `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2"` due to error (3/4): Bundler::Source::Git::GitCommandError Git error: command `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2"` in directory /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/omniauth-8385bc0da47e has failed.
If this error persists you could try removing the cache directory '/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2'*** DBG ***
PID:94856 DBG[strbuf_getcwd()]
PID:94856 TIME:649649505 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94856 >>DBG<< not expected value!

-----[DBG] PID:94856 -----
0x550612 <die_builtin+0x32> at /home/USER/bin/git
0x5500d9 <die_errno+0xc9> at /home/USER/bin/git
0x526f67 <setup_git_directory_gently+0x677> at /home/USER/bin/git
0x405635 <handle_builtin+0x145> at /home/USER/bin/git
0x404fcd <cmd_main+0xfd> at /home/USER/bin/git
0x47f779 <main+0x69> at /home/USER/bin/git
0x404d8f <_start+0x16f> at /home/USER/bin/git
DBG fatal: Unable to read current working directory: Permission denied

----------------

Retrying `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2"` due to error (4/4): Bundler::Source::Git::GitCommandError Git error: command `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2"` in directory /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/omniauth-8385bc0da47e has failed.
If this error persists you could try removing the cache directory '/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2'*** DBG ***
PID:94859 DBG[strbuf_getcwd()]
PID:94859 TIME:672228216 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94859 >>DBG<< not expected value!

-----[DBG] PID:94859 -----
0x550612 <die_builtin+0x32> at /home/USER/bin/git
0x5500d9 <die_errno+0xc9> at /home/USER/bin/git
0x526f67 <setup_git_directory_gently+0x677> at /home/USER/bin/git
0x405635 <handle_builtin+0x145> at /home/USER/bin/git
0x404fcd <cmd_main+0xfd> at /home/USER/bin/git
0x47f779 <main+0x69> at /home/USER/bin/git
0x404d8f <_start+0x16f> at /home/USER/bin/git
DBG fatal: Unable to read current working directory: Permission denied

----------------

Git error: command `git fetch --force --quiet --tags
"/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2"`
in directory /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/omniauth-8385bc0da47e has failed.
If this error persists you could try removing the cache directory
'/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2'

=== DEBUG OUTPUT END ===

Debug meassages have time stamps with time in nanoseconds and PIDs printed.



On another server with same OS configuration there was problem with:

$ npm install

> openproject@0.1.0 postinstall /usr/home/USER/openproject
> cd frontend && npm install

npm ERR! git clone --template=/home/USER/.npm/_git-remotes/_templates --mirror git://github.com/opf/angular-context-menu.git /home/USER/.npm/_git-remotes/git-github-com-opf-angular-context-menu-git-a908eccaec323cd66973d58af4965694bdff16a1-d8746dcc: Cloning into bare repository '/home/USER/.npm/_git-remotes/git-github-com-opf-angular-context-menu-git-a908eccaec323cd66973d58af4965694bdff16a1-d8746dcc'...
npm ERR! git clone --template=/home/USER/.npm/_git-remotes/_templates --mirror git://github.com/opf/angular-context-menu.git /home/USER/.npm/_git-remotes/git-github-com-opf-angular-context-menu-git-a908eccaec323cd66973d58af4965694bdff16a1-d8746dcc: fatal: Could not get current working directory: Permission denied
npm ERR! git clone --template=/home/USER/.npm/_git-remotes/_templates --mirror git://github.com/finnlabs/angular-modal.git /home/USER/.npm/_git-remotes/git-github-com-finnlabs-angular-modal-git-d45eb9ceb720b8785613ba89ba0f14f8ab197569-619b970d: Cloning into bare repository '/home/USER/.npm/_git-remotes/git-github-com-finnlabs-angular-modal-git-d45eb9ceb720b8785613ba89ba0f14f8ab197569-619b970d'...
npm ERR! git clone --template=/home/USER/.npm/_git-remotes/_templates --mirror git://github.com/finnlabs/angular-modal.git /home/USER/.npm/_git-remotes/git-github-com-finnlabs-angular-modal-git-d45eb9ceb720b8785613ba89ba0f14f8ab197569-619b970d: fatal: Could not get current working directory: Permission denied
npm ERR! git clone --template=/home/USER/.npm/_git-remotes/_templates --mirror git://github.com/sparkalow/angular-truncate.git /home/USER/.npm/_git-remotes/git-github-com-sparkalow-angular-truncate-git-fdf60fda265042d12e9414b5354b2cc52f1419de-3ed663f6: Cloning into bare repository '/home/USER/.npm/_git-remotes/git-github-com-sparkalow-angular-truncate-git-fdf60fda265042d12e9414b5354b2cc52f1419de-3ed663f6'...
npm ERR! git clone --template=/home/USER/.npm/_git-remotes/_templates --mirror git://github.com/sparkalow/angular-truncate.git /home/USER/.npm/_git-remotes/git-github-com-sparkalow-angular-truncate-git-fdf60fda265042d12e9414b5354b2cc52f1419de-3ed663f6: fatal: Could not get current working directory: Permission denied
npm ERR! FreeBSD 10.3-STABLE
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install"
npm ERR! node v4.7.2
npm ERR! npm  v4.0.5
npm ERR! code 128

npm ERR! Command failed: git clone --template=/home/USER/.npm/_git-remotes/_templates --mirror git://github.com/opf/angular-context-menu.git /home/USER/.npm/_git-remotes/git-github-com-opf-angular-context-menu-git-a908eccaec323cd66973d58af4965694bdff16a1-d8746dcc
npm ERR! Cloning into bare repository '/home/USER/.npm/_git-remotes/git-github-com-opf-angular-context-menu-git-a908eccaec323cd66973d58af4965694bdff16a1-d8746dcc'...
npm ERR! fatal: Could not get current working directory: Permission denied
npm ERR! 
npm ERR! 
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     /usr/home/USER/openproject/frontend/npm-debug.log

npm ERR! FreeBSD 10.3-STABLE
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install"
npm ERR! node v4.7.2
npm ERR! npm  v4.0.5
npm ERR! code ELIFECYCLE
npm ERR! openproject@0.1.0 postinstall: `cd frontend && npm install`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the openproject@0.1.0 postinstall script 'cd frontend && npm install'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the openproject package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     cd frontend && npm install
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs openproject
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls openproject
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /usr/home/USER/openproject/npm-debug.log

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

[René Scharfe]

Am 06.03.2017 um 17:10 schrieb Zenobiusz Kunegunda:
> OS: FreeBSD 10.3-STABLE
>
> Story: I was trying to install openproject using this manual
> https://www.openproject.org/open-source/download/manual-installation-guide/
>
>  Everything was fine till command $ bundle install --deployment
> --without postgres sqlite development test therubyracer docker
>
> works witg git version: 1.9.5 ( branch from repo ) does not work with
> git version: 2.10 ( branch from from repo ) 2.11 ( both from FreeBSD
> and from git repository) 2.12 ( branch from repo )
>
> On another server that passed but there was npm problem.
>
> This is error for $ bundle install --deployment --without postgres
> sqlite development test therubyracer docker

I suspect you might get better responses from the makers of bundler 
(http://bundler.io/, http://groups.google.com/group/ruby-bundler).

> Fetching dependency metadata from https://rubygems.org/. fatal: Could
> not get current working directory: Permission denied
>
> Retrying `git fetch --force --quiet --tags
> "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"`
> due to error (2/4): Bundler::Source::Git::GitCommandError Git error:
> command `git fetch --force --quiet --tags
> "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"`
> in directory
> /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2
> has failed. If this error persists you could try removing the cache
> directory
> '/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7'fatal:
> Could not get current working directory: Permission denied

These long and repetitive messages make me feel dizzy.  So git fetch was 
executed in 
"/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2" 
and reported that it was not allowed to get the current working 
directory, right?  That's odd.

I suspect that older versions of git ignored the error, used an empty 
string and went with that instead of an absolute path, but that's just a 
guess.

Was git perhaps started by bundler under a different user ID?  You could 
check that e.g. by printing the return value of geteuid(2).

"/bin/pwd -P" executed in the same directory under the same user ID as 
git should error out and report "Permission denied" as well.  Are the 
permissions bits and ACLs for that directory and its parents OK?

Thanks,
René

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

[Zenobiusz Kunegunda]

OK, I printed euids inside function calling getcwd(). 
Every single EUID is the same and have expected value. The same as any other local application run by this user. Permissions of every directory in the path are OK. 

/bin/pwd -P inside directory returned exact path and exited with exit status 0.





Od: "René Scharfe" <l.s.r@web.de>
Do: "Zenobiusz Kunegunda" <zenobiusz.kunegunda@interia.pl>; 
Wysłane: 18:38 Środa 2017-03-08
Temat: Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

> 
>> Am 06.03.2017 um 17:10 schrieb Zenobiusz Kunegunda:
>> OS: FreeBSD 10.3-STABLE
>>
>> Story: I was trying to install openproject using this manual
>> https://www.openproject.org/open-source/download/manual-installation-guide/
>>
>>  Everything was fine till command $ bundle install --deployment
>> --without postgres sqlite development test therubyracer docker
>>
>> works witg git version: 1.9.5 ( branch from repo ) does not work with
>> git version: 2.10 ( branch from from repo ) 2.11 ( both from FreeBSD
>> and from git repository) 2.12 ( branch from repo )
>>
>> On another server that passed but there was npm problem.
>>
>> This is error for $ bundle install --deployment --without postgres
>> sqlite development test therubyracer docker
> 
> I suspect you might get better responses from the makers of bundler 
> (http://bundler.io/, http://groups.google.com/group/ruby-bundler).
> 
>> Fetching dependency metadata from https://rubygems.org/. fatal: Could
>> not get current working directory: Permission denied
>>
>> Retrying `git fetch --force --quiet --tags
>> "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"`
>> due to error (2/4): Bundler::Source::Git::GitCommandError Git error:
>> command `git fetch --force --quiet --tags
>> "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"`
>> in directory
>> /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2
>> has failed. If this error persists you could try removing the cache
>> directory
>> '/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7'fatal:
>> Could not get current working directory: Permission denied
> 
> These long and repetitive messages make me feel dizzy.  So git fetch was 
> executed in 
> "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2" 
> and reported that it was not allowed to get the current working 
> directory, right?  That's odd.
> 
> I suspect that older versions of git ignored the error, used an empty 
> string and went with that instead of an absolute path, but that's just a 
> guess.
> 
> Was git perhaps started by bundler under a different user ID?  You could 
> check that e.g. by printing the return value of geteuid(2).
> 
> "/bin/pwd -P" executed in the same directory under the same user ID as 
> git should error out and report "Permission denied" as well.  Are the 
> permissions bits and ACLs for that directory and its parents OK?
> 
> Thanks,
> René
> 
> 

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

[Zenobiusz Kunegunda]

OK, I printed euids inside function calling getcwd(). 
Every single EUID is the same and have expected value. The same as any
other local application run by this user. Permissions of every directory in
the path are OK. 

/bin/pwd -P inside directory returned exact path and exited with exit
status 0.Od: "René Scharfe" <l.s.r@web.de>
Do: "Zenobiusz Kunegunda" <zenobiusz.kunegunda@interia.pl>; 
Wysłane: 18:38 Środa 2017-03-08
Temat: Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

> 
>> Am 06.03.2017 um 17:10 schrieb Zenobiusz Kunegunda:
>> OS: FreeBSD 10.3-STABLE
>>
>> Story: I was trying to install openproject using this manual
>> https://www.openproject.org/open-source/download/manual-installation-guide/
>>
>>  Everything was fine till command $ bundle install --deployment
>> --without postgres sqlite development test therubyracer docker
>>
>> works witg git version: 1.9.5 ( branch from repo ) does not work with
>> git version: 2.10 ( branch from from repo ) 2.11 ( both from FreeBSD
>> and from git repository) 2.12 ( branch from repo )
>>
>> On another server that passed but there was npm problem.
>>
>> This is error for $ bundle install --deployment --without postgres
>> sqlite development test therubyracer docker
> 
> I suspect you might get better responses from the makers of bundler 
> (http://bundler.io/, http://groups.google.com/group/ruby-bundler).
> 
>> Fetching dependency metadata from https://rubygems.org/. fatal: Could
>> not get current working directory: Permission denied
>>
>> Retrying `git fetch --force --quiet --tags
>> "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"`
>> due to error (2/4): Bundler::Source::Git::GitCommandError Git error:
>> command `git fetch --force --quiet --tags
>> "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"`
>> in directory
>> /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2
>> has failed. If this error persists you could try removing the cache
>> directory
>> '/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7'fatal:
>> Could not get current working directory: Permission denied
> 
> These long and repetitive messages make me feel dizzy.  So git fetch was 
> executed in 
> "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2" 
> and reported that it was not allowed to get the current working 
> directory, right?  That's odd.
> 
> I suspect that older versions of git ignored the error, used an empty 
> string and went with that instead of an absolute path, but that's just a 
> guess.
> 
> Was git perhaps started by bundler under a different user ID?  You could 
> check that e.g. by printing the return value of geteuid(2).
> 
> "/bin/pwd -P" executed in the same directory under the same user ID as 
> git should error out and report "Permission denied" as well.  Are the 
> permissions bits and ACLs for that directory and its parents OK?
> 
> Thanks,
> René
> 
> 

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

[René Scharfe]

Am 09.03.2017 um 12:01 schrieb Zenobiusz Kunegunda:
> OK, I printed euids inside function calling getcwd(). Every single
> EUID is the same and have expected value. The same as any other local
> application run by this user. Permissions of every directory in the
> path are OK.
>
> /bin/pwd -P inside directory returned exact path and exited with exit
> status 0.

Weird.

I tried to reproduce the behavior on FreeBSD 10.3, unsuccessfully.  I 
tried with Ruby 2.2 from the ports tree and Ruby 2.3 installed with 
rbenv, and with git 2.6.4 from the ports tree and a self-compiled 
version of the current master branch.

You could try to bisect the issue to find which commit to git caused the 
behavior change, but that will be a tedious process (compile and install 
an intermediate version, run bundle install up to the point of interest 
then hit Ctrl-C, clean up somehow, run "git bisect good" or "git bisect 
bad" in the git source tree depending on the outcome of bundle, repeat 
ca. twelve times more).

But I suspect the cause of the problem hides somewhere else.  Why would 
pwd(1) be able to call getcwd(3) just fine, while git gets an EPERM 
error for the same call?  I'm stumped.

René

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

[Zenobiusz Kunegunda]

Tested on ZFS filesystem



    [test0@s0]:<~>$ mkdir '232222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222'
    [test0@s0]:<~>$ cd 232222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222/
    [test0@s0]:<~/232222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222>$ git status
    fatal: Unable to read current working directory: Permission denied

    [test0@s0]:<~/232222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222>$ git blahblahblah
    fatal: Unable to read current working directory: Permission denied


But when I create directory with same name (232...) as it's subdirectory everything works as expected inside that subdirectory.Od: "René Scharfe" &lt;l.s.r@web.de>
Do: "Zenobiusz Kunegunda" &lt;zenobiusz.kunegunda@interia.pl>; 
Wysłane: 22:18 Sobota 2017-03-11
Temat: Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

> 
>> Am 09.03.2017 um 12:01 schrieb Zenobiusz Kunegunda:
>> OK, I printed euids inside function calling getcwd(). Every single
>> EUID is the same and have expected value. The same as any other local
>> application run by this user. Permissions of every directory in the
>> path are OK.
>>
>> /bin/pwd -P inside directory returned exact path and exited with exit
>> status 0.
> 
> Weird.
> 
> I tried to reproduce the behavior on FreeBSD 10.3, unsuccessfully.  I 
> tried with Ruby 2.2 from the ports tree and Ruby 2.3 installed with 
> rbenv, and with git 2.6.4 from the ports tree and a self-compiled 
> version of the current master branch.
> 
> You could try to bisect the issue to find which commit to git caused the 
> behavior change, but that will be a tedious process (compile and install 
> an intermediate version, run bundle install up to the point of interest 
> then hit Ctrl-C, clean up somehow, run "git bisect good" or "git bisect 
> bad" in the git source tree depending on the outcome of bundle, repeat 
> ca. twelve times more).
> 
> But I suspect the cause of the problem hides somewhere else.  Why would 
> pwd(1) be able to call getcwd(3) just fine, while git gets an EPERM 
> error for the same call?  I'm stumped.
> 
> René
> 
> 

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

[Zenobiusz Kunegunda]

Bisecting: 0 revisions left to test after this (roughly 0 steps)
[a26bc613a64ac2c7ee69a50675e61b004a26382d] pretty.c: make git_pretty_formats_config return -1 on git_config_string failure

This is what I found with git bisect Od: "René Scharfe" <l.s.r@web.de>
Do: "Zenobiusz Kunegunda" <zenobiusz.kunegunda@interia.pl>; 
Wysłane: 22:18 Sobota 2017-03-11
Temat: Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

> 
>> Am 09.03.2017 um 12:01 schrieb Zenobiusz Kunegunda:
>> OK, I printed euids inside function calling getcwd(). Every single
>> EUID is the same and have expected value. The same as any other local
>> application run by this user. Permissions of every directory in the
>> path are OK.
>>
>> /bin/pwd -P inside directory returned exact path and exited with exit
>> status 0.
> 
> Weird.
> 
> I tried to reproduce the behavior on FreeBSD 10.3, unsuccessfully.  I 
> tried with Ruby 2.2 from the ports tree and Ruby 2.3 installed with 
> rbenv, and with git 2.6.4 from the ports tree and a self-compiled 
> version of the current master branch.
> 
> You could try to bisect the issue to find which commit to git caused the 
> behavior change, but that will be a tedious process (compile and install 
> an intermediate version, run bundle install up to the point of interest 
> then hit Ctrl-C, clean up somehow, run "git bisect good" or "git bisect 
> bad" in the git source tree depending on the outcome of bundle, repeat 
> ca. twelve times more).
> 
> But I suspect the cause of the problem hides somewhere else.  Why would 
> pwd(1) be able to call getcwd(3) just fine, while git gets an EPERM 
> error for the same call?  I'm stumped.
> 
> René
> 
> 

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

[René Scharfe]

Am 13.03.2017 um 13:23 schrieb Zenobiusz Kunegunda:
> Tested on ZFS filesystem
> 
> 
> 
>     [test0@s0]:<~>$ mkdir '232222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222'
>     [test0@s0]:<~>$ cd 232222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222/
>     [test0@s0]:<~/232222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222>$ git status
>     fatal: Unable to read current working directory: Permission denied
> 
>     [test0@s0]:<~/232222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222>$ git blahblahblah
>     fatal: Unable to read current working directory: Permission denied
> 
> 
> But when I create directory with same name (232...) as it's subdirectory everything works as expected inside that subdirectory.

Earlier I checked on UFS.  Now I tried the above commands on ZFS,
but they work as expected:

  $ git status
  fatal: Not a git repository (or any parent up to mount point /src)
  Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

Git checks out if it's in a git repository and if the current
working directory isn't one then it goes to the parent directories
recursively until it finds the root of a repo or a file system
boundary or / (root).

You can see where your invocation goes to with:

	$ strace git status 2>&1 >/dev/null | grep chdir

René

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

[René Scharfe]

Am 13.03.2017 um 14:23 schrieb Zenobiusz Kunegunda:
> Bisecting: 0 revisions left to test after this (roughly 0 steps)
> [a26bc613a64ac2c7ee69a50675e61b004a26382d] pretty.c: make git_pretty_formats_config return -1 on git_config_string failure
>
> This is what I found with git bisect

Strange, I don't think git_pretty_formats_config() is even called by git 
status.

René

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

[Zenobiusz Kunegunda]

Od: "René Scharfe" <l.s.r@web.de>
Do: "Zenobiusz Kunegunda" <zenobiusz.kunegunda@interia.pl>; 
Wysłane: 22:31 Poniedziałek 2017-03-13
Temat: Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

> 
>> Am 13.03.2017 um 14:23 schrieb Zenobiusz Kunegunda:
>> Bisecting: 0 revisions left to test after this (roughly 0 steps)
>> [a26bc613a64ac2c7ee69a50675e61b004a26382d] pretty.c: make git_pretty_formats_config return -1 on git_config_string failure
>>
>> This is what I found with git bisect
> 
> Strange, I don't think git_pretty_formats_config() is even called by git 
> status.
> 
> René
> 
> 


a26bc613a64ac2c7ee69a50675e61b004a26382d - is actually working revision

The question is - is git history linear enough for git bisect to produce any useful result? Gitk produces rather complicated diagram. Especially for year 2014. I'm not sure about reliability of this method. Or maybe it should be used in a specific way I'm not aware of. If you have any advices how to use it in this specific case, please let me know. 

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

[Zenobiusz Kunegunda]

Output of 

truss git status 2>&1 >/dev/null |grep chdir

is empty when git status fails.


Also git status succeeded when run as root.Od: "René Scharfe" <l.s.r@web.de>
Do: "Zenobiusz Kunegunda" <zenobiusz.kunegunda@interia.pl>; 
Wysłane: 18:32 Poniedziałek 2017-03-13
Temat: Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

> 
>> Am 13.03.2017 um 13:23 schrieb Zenobiusz Kunegunda:
>> Tested on ZFS filesystem
>> 
>> 
>> 
>>     [test0@s0]:<~>$ mkdir '232222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222'
>>     [test0@s0]:<~>$ cd 232222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222/
>>     [test0@s0]:<~/232222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222>$ git status
>>     fatal: Unable to read current working directory: Permission denied
>> 
>>     [test0@s0]:<~/232222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222>$ git blahblahblah
>>     fatal: Unable to read current working directory: Permission denied
>> 
>> 
>> But when I create directory with same name (232...) as it's subdirectory everything works as expected inside that subdirectory.
> 
> Earlier I checked on UFS.  Now I tried the above commands on ZFS,
> but they work as expected:
> 
>   $ git status
>   fatal: Not a git repository (or any parent up to mount point /src)
>   Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
> 
> Git checks out if it's in a git repository and if the current
> working directory isn't one then it goes to the parent directories
> recursively until it finds the root of a repo or a file system
> boundary or / (root).
> 
> You can see where your invocation goes to with:
> 
> 	$ strace git status 2>&1 >/dev/null | grep chdir
> 
> René
> 
> 

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

[René Scharfe]

Am 14.03.2017 um 08:44 schrieb Zenobiusz Kunegunda:
> Od: "René Scharfe" <l.s.r@web.de> Do: "Zenobiusz Kunegunda"
> <zenobiusz.kunegunda@interia.pl>; Wysłane: 22:31 Poniedziałek
> 2017-03-13 Temat: Re: fatal: Could not get current working directory:
> Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |
>
>>
>>> Am 13.03.2017 um 14:23 schrieb Zenobiusz Kunegunda: Bisecting: 0
>>> revisions left to test after this (roughly 0 steps)
>>> [a26bc613a64ac2c7ee69a50675e61b004a26382d] pretty.c: make
>>> git_pretty_formats_config return -1 on git_config_string failure
>>>
>>> This is what I found with git bisect
>>
>> Strange, I don't think git_pretty_formats_config() is even called
>> by git status.
>>
>> René
>>
>>
>
>
> a26bc613a64ac2c7ee69a50675e61b004a26382d - is actually working
> revision
>
> The question is - is git history linear enough for git bisect to
> produce any useful result? Gitk produces rather complicated diagram.
> Especially for year 2014. I'm not sure about reliability of this
> method. Or maybe it should be used in a specific way I'm not aware
> of. If you have any advices how to use it in this specific case,
> please let me know.

Ah, right, I didn't pay enough attention, sorry.  Step 0 is the last 
one, but you need to rate it as good or bad before reset presents the 
result.  History is not really linear in git's own repository.  But if 
you didn't reset bisect's status you may still be able to finish it by 
running "git bisect good a26bc613" now.

(And if that doesn't work then at least you now have a much quicker way 
to check using the long directory name..)

René

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

[Zenobiusz Kunegunda]

Od: "René Scharfe" <l.s.r@web.de>
Do: "Zenobiusz Kunegunda" <zenobiusz.kunegunda@interia.pl>; 
Wysłane: 18:59 Wtorek 2017-03-14
Temat: Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

> 
>> Am 14.03.2017 um 08:44 schrieb Zenobiusz Kunegunda:
>> Od: "René Scharfe" <l.s.r@web.de> Do: "Zenobiusz Kunegunda"
>> <zenobiusz.kunegunda@interia.pl>; Wysłane: 22:31 Poniedziałek
>> 2017-03-13 Temat: Re: fatal: Could not get current working directory:
>> Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |
>>
>>>
>>>> Am 13.03.2017 um 14:23 schrieb Zenobiusz Kunegunda: Bisecting: 0
>>>> revisions left to test after this (roughly 0 steps)
>>>> [a26bc613a64ac2c7ee69a50675e61b004a26382d] pretty.c: make
>>>> git_pretty_formats_config return -1 on git_config_string failure
>>>>
>>>> This is what I found with git bisect
>>>
>>> Strange, I don't think git_pretty_formats_config() is even called
>>> by git status.
>>>
>>> René
>>>
>>>
>>
>>
>> a26bc613a64ac2c7ee69a50675e61b004a26382d - is actually working
>> revision
>>
>> The question is - is git history linear enough for git bisect to
>> produce any useful result? Gitk produces rather complicated diagram.
>> Especially for year 2014. I'm not sure about reliability of this
>> method. Or maybe it should be used in a specific way I'm not aware
>> of. If you have any advices how to use it in this specific case,
>> please let me know.
> 
> Ah, right, I didn't pay enough attention, sorry.  Step 0 is the last 
> one, but you need to rate it as good or bad before reset presents the 
> result.  History is not really linear in git's own repository.  But if 
> you didn't reset bisect's status you may still be able to finish it by 
> running "git bisect good a26bc613" now.
> 
> (And if that doesn't work then at least you now have a much quicker way 
> to check using the long directory name..)
> 
> René
> 
> 

Oh, my bad. Haven't been using git bisect for quiet a while and forgot to rate.
Ok, so I did bisect again

$ 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
    
    Convert setup_git_directory_gently_1() and its helper functions
    setup_explicit_git_dir(), setup_discovered_git_dir() and
    setup_bare_git_dir() to use a struct strbuf to hold the current working
    directory.  Replacing the PATH_MAX-sized buffer used before removes a
    path length limition on some file systems.  The functions are converted
    all in one go because they all read and write the variable cwd.
    
    Signed-off-by: Rene Scharfe <l.s.r@web.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

:100644 100644 0a22f8bd1d631fe5f0afe1d84162ca4064a00e4f 937dad503c28681d7c21f5dc300ea943cfe5b17a M	setup.c

$ git bisect log
git bisect start
# bad: [b260d265e189728b26e50506ac6ffab6a7d588da] Git 2.2
git bisect bad b260d265e189728b26e50506ac6ffab6a7d588da
# good: [83332636f575f00edff8f3afb15a2f96885bf417] Git 1.9.5
git bisect good 83332636f575f00edff8f3afb15a2f96885bf417
# good: [9181365b856a63f8c5486ad0fe48f1cd60852da3] Merge branch 'maint-1.8.5' into maint-1.9
git bisect good 9181365b856a63f8c5486ad0fe48f1cd60852da3
# good: [9181365b856a63f8c5486ad0fe48f1cd60852da3] Merge branch 'maint-1.8.5' into maint-1.9
git bisect good 9181365b856a63f8c5486ad0fe48f1cd60852da3
# good: [ba655d15b58ab2a00032b74e5b2617a0b658a01f] Merge branch 'sk/mingw-main'
git bisect good ba655d15b58ab2a00032b74e5b2617a0b658a01f
# bad: [88e7dff93d7010bb2974f8e1599a4e53c73e18f3] Merge branch 'jk/prune-top-level-refs-after-packing'
git bisect bad 88e7dff93d7010bb2974f8e1599a4e53c73e18f3
# good: [8a7b034d6d451491dbcfaebc3d4ed4f08c756822] add tests for `git_config_get_string_const()`
git bisect good 8a7b034d6d451491dbcfaebc3d4ed4f08c756822
# bad: [f655651e09b9fa7bf8ff13f1b4a5b16c7956e4cf] Merge branch 'rs/strbuf-getcwd'
git bisect bad f655651e09b9fa7bf8ff13f1b4a5b16c7956e4cf
# good: [aa544bfbc6eb11e4f0471f3144d3e3ac75c0e4a9] Sync with 2.0.4
git bisect good aa544bfbc6eb11e4f0471f3144d3e3ac75c0e4a9
# good: [212d781c967317a05a704609ddf3ffc8a09f8590] Merge branch 'jk/fix-profile-feedback-build'
git bisect good 212d781c967317a05a704609ddf3ffc8a09f8590
# good: [44ceb79f84b0f339147d2d44e4bb50cc472be03e] Merge branch 'jk/pretty-empty-format'
git bisect good 44ceb79f84b0f339147d2d44e4bb50cc472be03e
# bad: [4d3ab44d26c47d100cec39d0ef9ed9746eb7e454] use xgetcwd() to set $GIT_DIR
git bisect bad 4d3ab44d26c47d100cec39d0ef9ed9746eb7e454
# bad: [251277acdf8c8dee59bdd0e9e7b7e3502226cf9d] abspath: use strbuf_getcwd() to remember original working directory
git bisect bad 251277acdf8c8dee59bdd0e9e7b7e3502226cf9d
# good: [d13a0a97e097c6a601bafc529a716477cc94dc20] unix-sockets: use strbuf_getcwd()
git bisect good d13a0a97e097c6a601bafc529a716477cc94dc20
# bad: [7333ed1788b4f2b162a35003044d77a716732a1f] setup: convert setup_git_directory_gently_1 et al. to strbuf
git bisect bad 7333ed1788b4f2b162a35003044d77a716732a1f
# first bad commit: [7333ed1788b4f2b162a35003044d77a716732a1f] setup: convert setup_git_directory_gently_1 et al. to strbuf

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

[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:

	#include <errno.h>
	#include <limits.h>
	#include <stdio.h>
	#include <string.h>
	#include <unistd.h>

	int main(int argc, char **argv)
	{
		char buf[PATH_MAX];
		int last_errno = 0;
		size_t len;

		for (len = 0; len <= PATH_MAX; len++) {
			errno = 0;
			getcwd(buf, len);
			if (errno != last_errno) {
				printf("len = %lu, errno = %d, %s\n",
					len, errno, strerror(errno));
			}
			last_errno = errno;
		}
		return 0;
	}

It runs getcwd(2) with buffer sizes from 0 to PATH_MAX and reports when 
the error code changes along the way.  Let's call it test_getcwd.  And 
here's what I get on FreeBSD 10.3:

	$ mkdir /tmp/a
	$ cd /tmp/a

	$ chmod 100 /tmp/a
	$ test_getcwd
	len = 0, errno = 22, Invalid argument
	len = 1, errno = 34, Result too large
	len = 7, errno = 0, No error: 0

	$ chmod 000 /tmp/a
	$ test_getcwd
	len = 0, errno = 22, Invalid argument
	len = 1, errno = 34, Result too large
	len = 2, errno = 13, Permission denied
	len = 7, errno = 0, No error: 0

So if we don't have execute permission and our buffer is at least one 
char long but still too small then we get EACCES (13).  If we don't have 
read permissions and our buffer is big enough then the call succeeds. 
strbuf_getcwd() expects to get ERANGE (34) and nothing else when the 
buffer is too small.

I'd say it's a bug in FreeBSD -- reporting permission denied or success 
based on the size of the supplied buffer makes no sense to me, at least.

The initial buffer size used by strbuf_getcwd() is 128, so you should be 
fine as long as the absolute path to your repository is shorter than 
that.  You should also be fine if you have execute permissions on the 
directory.

And here I'm puzzled again -- you probably have sufficient permissions 
set up for your user, right?  What does the test program report for your 
problematic repository and its parent directories?

René

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

[René Scharfe]

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);
+	if (cwd) {
+		size_t len = strlen(cwd);
+		strbuf_attach(sb, cwd, len, len + 1);
+		return 0;
+	}
 
 	for (;; guessed_len *= 2) {
 		strbuf_grow(sb, guessed_len);
-- 
2.12.0

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

[Stefan Beller]

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?

Thanks,
Stefan

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

[René Scharfe]

Am 17.03.2017 um 20:45 schrieb Stefan Beller:
> 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.").

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é

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

[Jeff King]

On Fri, Mar 17, 2017 at 10:07:18PM +0100, René Scharfe wrote:

> >   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.

My big question is what happens on other platforms when they see a NULL
(but 0-sized) buffer. Any reasonable implementation would just return
ERANGE and we'd fall back to the existing code. But we often have to deal with unreasonable ones.

So do we need a "my OS understands getcwd(NULL)" build knob?

-Peff

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

[René Scharfe]

Am 17.03.2017 um 23:29 schrieb Jeff King:
> On Fri, Mar 17, 2017 at 10:07:18PM +0100, René Scharfe wrote:
>
>>>   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.
>
> My big question is what happens on other platforms when they see a NULL
> (but 0-sized) buffer. Any reasonable implementation would just return
> ERANGE and we'd fall back to the existing code. But we often have to deal with unreasonable ones.
>
> So do we need a "my OS understands getcwd(NULL)" build knob?

POSIX specifies the behavior in this case as unspecified.  An 
implementation could offer a different extension, and e.g. return a 
pointer to a static buffer.  So the answer would probably be "yes" if 
this was a patch meant for public consumption.  For now it's only 
compatible with BSDs, Windows, MacOSX, Linux. :)

René

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

[Zenobiusz Kunegunda]

Od: "René Scharfe" <l.s.r@web.de>
Do: "Zenobiusz Kunegunda" <zenobiusz.kunegunda@interia.pl>; 
Wysłane: 22:31 Środa 2017-03-15
Temat: Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

> 
> > 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:
> 
> 	#include 
> 	#include 
> 	#include 
> 	#include 
> 	#include 
> 
> 	int main(int argc, char **argv)
> 	{
> 		char buf[PATH_MAX];
> 		int last_errno = 0;
> 		size_t len;
> 
> 		for (len = 0; len <= PATH_MAX; len++) {
> 			errno = 0;
> 			getcwd(buf, len);
> 			if (errno != last_errno) {
> 				printf("len = %lu, errno = %d, %s\n",
> 					len, errno, strerror(errno));
> 			}
> 			last_errno = errno;
> 		}
> 		return 0;
> 	}
> 
> It runs getcwd(2) with buffer sizes from 0 to PATH_MAX and reports when 
> the error code changes along the way.  Let's call it test_getcwd.  And 
> here's what I get on FreeBSD 10.3:
> 
> 	$ mkdir /tmp/a
> 	$ cd /tmp/a
> 
> 	$ chmod 100 /tmp/a
> 	$ test_getcwd
> 	len = 0, errno = 22, Invalid argument
> 	len = 1, errno = 34, Result too large
> 	len = 7, errno = 0, No error: 0
> 
> 	$ chmod 000 /tmp/a
> 	$ test_getcwd
> 	len = 0, errno = 22, Invalid argument
> 	len = 1, errno = 34, Result too large
> 	len = 2, errno = 13, Permission denied
> 	len = 7, errno = 0, No error: 0
> 
> So if we don't have execute permission and our buffer is at least one 
> char long but still too small then we get EACCES (13).  If we don't have 
> read permissions and our buffer is big enough then the call succeeds. 
> strbuf_getcwd() expects to get ERANGE (34) and nothing else when the 
> buffer is too small.
> 
> I'd say it's a bug in FreeBSD -- reporting permission denied or success 
> based on the size of the supplied buffer makes no sense to me, at least.
> 
> The initial buffer size used by strbuf_getcwd() is 128, so you should be 
> fine as long as the absolute path to your repository is shorter than 
> that.  You should also be fine if you have execute permissions on the 
> directory.
> 
> And here I'm puzzled again -- you probably have sufficient permissions 
> set up for your user, right?  What does the test program report for your 
> problematic repository and its parent directories?
> 
> René
> 
> 

This program produces same errors I get from git in every directory . But no errors at all when run as root. Here is example when run as reular user.

   $ getcwdtest 
   len = 0, errno = 22, Invalid argument
   len = 1, errno = 34, Result too large
   len = 2, errno = 13, Permission denied
   len = 19, errno = 0, No error: 0
   $ mkdir testdir
   $ cd testdir/
   $ getcwdtest 
   len = 0, errno = 22, Invalid argument
   len = 1, errno = 34, Result too large
   len = 9, errno = 13, Permission denied
   len = 27, errno = 0, No error: 0

But when run as root there is no permission denied errors. Filesystem is ZFS.

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

[Zenobiusz Kunegunda]

Od: "René Scharfe" <l.s.r@web.de>
Do: "Stefan Beller" <sbeller@google.com>; 
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

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

[René Scharfe]

Am 21.03.2017 um 14:29 schrieb Zenobiusz Kunegunda:
> 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

Yes, and I think we can take ZFS out of the equation.  As a regular user 
I get this with UFS and for $mode values of 000, 100 or 400 (with umask 
0022):

	$ mkdir -p /tmp/a/b && cd /tmp/a/b

	$ chmod $mode /tmp/a && getcwdtest
	len = 0, errno = 22, Invalid argument
	len = 1, errno = 34, Result too large
	len = 2, errno = 13, Permission denied
	len = 9, errno = 0, No error: 0

Only with both read and execute/search permissions for the intermediate 
directory I get rid of that irritating permission error for small buffers:

	$ chmod 500 /tmp/a && getcwdtest
	len = 0, errno = 22, Invalid argument
	len = 1, errno = 34, Result too large
	len = 9, errno = 0, No error: 0

So a workaround for you would be to run "chmod a+rx" (or similar) 
against all parent directories of your repository.  Another one would be 
to keep the path length below 128 characters (that's the initial buffer 
size in strbuf_getcwd()).

Have you been able to test the patch I sent on Friday by any chance?

Thanks,
René

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

[Zenobiusz Kunegunda]

After applying mentioned patch to git v2.12.0 I was not able to reproduce bug.Od: "René Scharfe" <l.s.r@web.de>
Do: "Zenobiusz Kunegunda" <zenobiusz.kunegunda@interia.pl>; 
Wysłane: 20:06 Wtorek 2017-03-21
Temat: Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

> 
>> Am 21.03.2017 um 14:29 schrieb Zenobiusz Kunegunda:
>> 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
> 
> Yes, and I think we can take ZFS out of the equation.  As a regular user 
> I get this with UFS and for $mode values of 000, 100 or 400 (with umask 
> 0022):
> 
> 	$ mkdir -p /tmp/a/b && cd /tmp/a/b
> 
> 	$ chmod $mode /tmp/a && getcwdtest
> 	len = 0, errno = 22, Invalid argument
> 	len = 1, errno = 34, Result too large
> 	len = 2, errno = 13, Permission denied
> 	len = 9, errno = 0, No error: 0
> 
> Only with both read and execute/search permissions for the intermediate 
> directory I get rid of that irritating permission error for small buffers:
> 
> 	$ chmod 500 /tmp/a && getcwdtest
> 	len = 0, errno = 22, Invalid argument
> 	len = 1, errno = 34, Result too large
> 	len = 9, errno = 0, No error: 0
> 
> So a workaround for you would be to run "chmod a+rx" (or similar) 
> against all parent directories of your repository.  Another one would be 
> to keep the path length below 128 characters (that's the initial buffer 
> size in strbuf_getcwd()).
> 
> Have you been able to test the patch I sent on Friday by any chance?
> 
> Thanks,
> René
> 
>