Re: [PATCH] strbuf: support long paths w/o read rights in strbuf_getcwd() on FreeBSD

[Zenobiusz Kunegunda]

Od: "Junio C Hamano" 
Do: "René Scharfe" ;
Wysłane: 2:40 Poniedziałek 2017-03-27
Temat: Re: [PATCH] strbuf: support long paths w/o read rights in 
strbuf_getcwd() on FreeBSD

> 
> Nicely analysed and fixed (or is the right word "worked around"?)
> 
> Thanks, will queue.
> 


Is this patch going to be included in next git version ( or sooner ) by any 
chance?

Thank you, everyone,  for your attention to the problem.

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@web.de>
Do: "Zenobiusz Kunegunda" zenobiusz.kunegu...@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é
> 
> 

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@web.de>
Do: "Stefan Beller" sbel...@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 |

[Zenobiusz Kunegunda]

Od: "René Scharfe" l@web.de>
Do: "Zenobiusz Kunegunda" zenobiusz.kunegu...@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@web.de>
Do: "Zenobiusz Kunegunda" zenobiusz.kunegu...@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@web.de> Do: "Zenobiusz Kunegunda"
>> zenobiusz.kunegu...@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@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@web.de>
Signed-off-by: Junio C Hamano <gits...@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 b

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@web.de>
Do: "Zenobiusz Kunegunda" zenobiusz.kunegu...@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 
>> '23222'
>> [test0@s0]:~>$ cd 
>> 23222/
>> 
>> [test0@s0]:~/23222>$
>>  git status
>> fatal: Unable to read current working directory: Permission denied
>> 
>> 
>> [test0@s0]:~/23222>$
>>  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 |

[Zenobiusz Kunegunda]

Od: "René Scharfe" l@web.de>
Do: "Zenobiusz Kunegunda" zenobiusz.kunegu...@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]

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@web.de>
Do: "Zenobiusz Kunegunda" zenobiusz.kunegu...@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]

Tested on ZFS filesystem



[test0@s0]:<~>$ mkdir 
'23222'
[test0@s0]:<~>$ cd 
23222/

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


[test0@s0]:<~/23222>$
 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" 
l....@web.de>
Do: "Zenobiusz Kunegunda" zenobiusz.kunegu...@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]

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@web.de>
Do: "Zenobiusz Kunegunda" zenobiusz.kunegu...@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@web.de>
Do: "Zenobiusz Kunegunda" zenobiusz.kunegu...@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é
> 
> 

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