[remote rejected] master -> master (n/a (unpacker error))

Today, just after someone else committed to my public repository I
started getting errors. Until then Git worked great.

Does anyone know what is going on here? Are there particular versions
of Git with known issues around this?


uname@hostname:~/dev/workspaces/scm-evaluations/welcome.git/install/git-config$
git push
Counting objects: 7, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 922 bytes, done.
Total 4 (delta 0), reused 4 (delta 0)
error: unable to create temporary sha1 filename ./objects/e6: File
exists

fatal: failed to write object
error: unpack failed: unpacker exited with error code
To ssh://git.projectbedrock.com/var/cache/git/welcome.git
 ! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to
'ssh://git.projectbedrock.com/var/cache/git/welcome.git'


As an aside, where the heck is the git bug tracker? I've searched, and
searched, and ... All I found is a Debian tracking system, which
appears to have no full text search capabilities.

On Wed, May 12, 2010 at 12:45 PM, Robert Buck [off-list ref] wrote:

Today, just after someone else committed to my public repository I
started getting errors. Until then Git worked great.

Does anyone know what is going on here? Are there particular versions
of Git with known issues around this?


uname@hostname:~/dev/workspaces/scm-evaluations/welcome.git/install/git-config$
git push
Counting objects: 7, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 922 bytes, done.
Total 4 (delta 0), reused 4 (delta 0)
error: unable to create temporary sha1 filename ./objects/e6: File
exists

fatal: failed to write object
error: unpack failed: unpacker exited with error code
To ssh://git.projectbedrock.com/var/cache/git/welcome.git
 ! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to
'ssh://git.projectbedrock.com/var/cache/git/welcome.git'

This is probably a permissions problem on the server. We use git over
ssh at $dayjob and we need to make sure everyone who pushes to a
repository on the server is a member of the same group and that the
repositories are created with "git init --shared" otherwise we run
into problems like this. Its not too much of an issue for us because
we have a maintainer model and the maintainers generally have the
right permissions and don't change frequently.

I think the "shared" part is probably the problem in this case because
you can both obviously create files on the server. Rhe problem appears
to be when one of you needs to update a file (or directory) the other
created.

To fix your current problem you'll just need to ssh into that server
and find the  welcome.git/objects directory and check the permissions
on the "e6" directory and its contents. You will keep running into
this problem until the permissions/sharing is sorted. Theres probably
a config variable which dictates the permissions to use when creating
objects on the server which is changed when you pass the "--shared"
option to "git init", but I'm not sure what its is (I see some man
pages in your future).

As an aside, where the heck is the git bug tracker? I've searched, and
searched, and ... All I found is a Debian tracking system, which
appears to have no full text search capabilities.

You're looking at it bugs, patches, questions all go to this mailing
list. The archive on gmane[1] is conveniently search-able.

[1] http://news.gmane.org/gmane.comp.version-control.git

Hi Robert,

Robert Buck wrote:

error: unable to create temporary sha1 filename ./objects/e6: File exists

Yeah, this error message is not so great.

The relevant code is in sha1_file.c.

	fd = create_tmpfile(tmpfile, sizeof(tmpfile), filename);
	while (fd < 0 && errno == EMFILE && unuse_one_window(packed_git, -1))
		fd = create_tmpfile(tmpfile, sizeof(tmpfile), filename);
	if (fd < 0) {
		if (errno == EACCES)
			return error("insufficient permission for adding an object to repository database %s\n", get_object_directory());
		else
			return error("unable to create temporary sha1 filename %s: %s\n", tmpfile, strerror(errno));
	}

create_tmpfile() creates a filename of the form
./objects/e6/tmp_obj_<random letters> and tries to open that file.
The random value is based on the current time and the process ID of
the current process.  If the file exists, it tries again with another
collection of random letters, up to 16384 times.

In your case, all 16384 trials yielded the same result: file already
existed.  As a workaround, I’d suggest

 rm -f .git/objects/??/tmp_obj_*

but it might be nice to get a listing with "ls -lR .git/objects" first
for post-mortem analysis.

And presumably the directory filled with temporary files that could
not be renamed to a proper name for some reason.  Probably a permissions
problem, as Chris suggested.

-- 8< --
Subject: write_loose_object(): improve error message for some mkstemp failures

If the .git/objects/ab/ directory fills up with tmp_obj_ files, the
result is a cryptic error:

  error: unable to create temporary sha1 filename ./objects/e6: File exists

Replace it with the slightly less cryptic

  error: cannot write temporary file under ./objects/e6: all the good filenames are taken

Reported-by: Robert Buck <redacted>
Signed-off-by: Jonathan Nieder <redacted>
---

As an aside, where the heck is the git bug tracker?

Here is an answer from the last time it came up[1]:

 See http://thread.gmane.org/gmane.comp.version-control.git/136500

 Short answer: the usual method is to report bugs to the list,
 preferably with a patch for t/ or even better, a fix. 

I've searched, and
searched, and ... All I found is a Debian tracking system, which
appears to have no full text search capabilities.

http://merkel.debian.org/~don/cgi/search.cgi
http://www.google.com/search?q=site:bugs.debian.org+"Package:+git"+"file+exists"

Thoughts?  Improvements?
Jonathan

[1] http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/680778/focus=141598

 sha1_file.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/sha1_file.c b/sha1_file.c
index 28c056e..a2aa301 100644
--- a/sha1_file.c
+++ b/sha1_file.c

@@ -2288,6 +2288,10 @@ static int write_loose_object(const unsigned char *sha1, char *hdr, int hdrlen,
 	if (fd < 0) {
 		if (errno == EACCES)
 			return error("insufficient permission for adding an object to repository database %s\n", get_object_directory());
+		else if (errno == EEXIST)
+			return error("cannot write temporary file under %s: "
+			             "all the good filenames are taken\n",
+			             tmpfile);
 		else
 			return error("unable to create temporary sha1 filename %s: %s\n", tmpfile, strerror(errno));
 	}

-- 
1.7.1

Thanks.

Yes, the repository is shared by several people, and in geographically
different locations, ssh-ing to the same host, under different groups.
So your recommendation would be to use --shared. But this won't work
so well out in the wild will it? Meaning, what if people's accounts
are NOT under the same group that is?

It would sound to me like in general, when one goes to production with
a git environment that some sort of chrooted account is preferable if
not highly recommended?

Bob

I am getting the same kinds of errors, but the resolutions offered here did
not work. After using the ideas (that there was a tmp_* file I did not have
perms to write to, I started doing some global searches. 

One such was this (from inside .git/objects):
# ls -alR | grep tmp
ls: reading directory ./97: Input/output error

So I tried:
# cd 97
# ls -l
ls: reading directory .: Input/output error
total 0K

To fix it, I did this:
# cd ..
# rm -fr ./97

The git push then worked fine.

I'll add a few more pieces to the puzzle. I have some of my git repositories
on a USB drive (the ones I get this issue with). I move it from system to
system. When git works, it works okay. But this irritant hits me about once
a week. My previous solution was to blow away the repo and rebuild it
(something suggested several times here). This is the first time I have
found a workaround.

These are my private repositories that hold my private files. I have a
github account I use for my public ones, plus my company has both a public
github and their own privately hosted github. So the same exact computer
systems (laptops and VMs) use all four with impunity. Almost all of them are
linux based -- a mix of CentOS 7.x and Linux Mint 14.x; all using git
v1.9.1. The one exception is osx. Thus the (brand new Toshiba 4T) USB drive
is built with the exFAT filesystem. When it works, it works okay; but as I
said, one of my dozen git repos will fail like this on a weekly basis. 

None of the items in my dockerhub or artifactory fail, nor do my rsnapshot
processes, or VLC/Banshee, etc. 

I've pretty much isolated it down to git. It is the ONLY app that fails. I
have noted in the past few months that the frequency of errors tells me I
cannot be using the USB drive for anything else while git is accessing the
drive. [mac specific: it is better when I use a USB 2.0 hub to plug the
drive in; we all are probably aware that the mac seems to have more issues
with USB 3.0...]

Anyway, I figured I'd toss this into the mix. Since it only happens once a
week or so, I cannot guarantee I'll have an update soon, but if someone is
curious, ping me, and I'll let you know when it happens again.

DL





--
View this message in context: http://git.661346.n2.nabble.com/remote-rejected-master-master-n-a-unpacker-error-tp5043046p7643470.html
Sent from the git mailing list archive at Nabble.com.