git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "René Scharfe" <l.s.r@web.de>
To: Zenobiusz Kunegunda <zenobiusz.kunegunda@interia.pl>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |
Date: Wed, 15 Mar 2017 22:30:26 +0100	[thread overview]
Message-ID: <7f25def4-9943-ae59-a649-b4348a79890e@web.de> (raw)
In-Reply-To: <ffntuqzgjgcfhebokbty@eduj>

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é

  reply	other threads:[~2017-03-15 21:31 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-06 16:10 fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 | Zenobiusz Kunegunda
2017-03-08 17:36 ` René Scharfe
2017-03-09 11:01   ` Zenobiusz Kunegunda
2017-03-11 21:17     ` René Scharfe
2017-03-13 12:23       ` Zenobiusz Kunegunda
2017-03-13 17:31         ` René Scharfe
2017-03-14 15:25           ` Zenobiusz Kunegunda
2017-03-13 13:23       ` Zenobiusz Kunegunda
2017-03-13 21:31         ` René Scharfe
2017-03-14  7:44           ` Zenobiusz Kunegunda
2017-03-14 17:59             ` René Scharfe
2017-03-15  9:44               ` Zenobiusz Kunegunda
2017-03-15 21:30                 ` René Scharfe [this message]
2017-03-17 19:34                   ` René Scharfe
2017-03-17 19:45                     ` Stefan Beller
2017-03-17 21:07                       ` René Scharfe
2017-03-17 22:29                         ` Jeff King
2017-03-17 22:50                           ` René Scharfe
2017-03-21 13:29                         ` Zenobiusz Kunegunda
2017-03-21 19:04                           ` René Scharfe
2017-03-22  8:30                             ` Zenobiusz Kunegunda
2017-03-21 10:08                   ` Zenobiusz Kunegunda
2017-03-09 11:11   ` Zenobiusz Kunegunda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7f25def4-9943-ae59-a649-b4348a79890e@web.de \
    --to=l.s.r@web.de \
    --cc=git@vger.kernel.org \
    --cc=zenobiusz.kunegunda@interia.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).