Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 369780

Summary: EOFException: Input did not match supplied length. 829 bytes are missing.
Product: [Technology] JGit Reporter: Eike Stepper <stepper>
Component: JGitAssignee: Project Inbox <jgit.core-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: critical    
Priority: P3 CC: maggie9in, Marc.Herbert, markward.schubert, math.clavel, mike, mjdenham, oman002, robin.rosenberg, spisek
Version: 1.3   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description Eike Stepper CLA 2012-01-26 04:39:34 EST 
JGit 1.3.0.201201241920	produces this error:

org.eclipse.jgit.api.errors.JGitInternalException: Exception caught during execution of commit command
	at org.eclipse.jgit.api.CommitCommand.call(CommitCommand.java:277)
	at org.eclipse.egit.core.op.CommitOperation.commit(CommitOperation.java:255)
	at org.eclipse.egit.core.op.CommitOperation.access$7(CommitOperation.java:233)
	at org.eclipse.egit.core.op.CommitOperation$1.run(CommitOperation.java:197)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2326)
	at org.eclipse.egit.core.op.CommitOperation.execute(CommitOperation.java:207)
	at org.eclipse.egit.ui.internal.commit.CommitUI$2.run(CommitUI.java:220)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.io.EOFException: Input did not match supplied length. 829 bytes are missing.
	at org.eclipse.jgit.storage.file.ObjectDirectoryInserter.shortInput(ObjectDirectoryInserter.java:237)
	at org.eclipse.jgit.storage.file.ObjectDirectoryInserter.toTemp(ObjectDirectoryInserter.java:168)
	at org.eclipse.jgit.storage.file.ObjectDirectoryInserter.insert(ObjectDirectoryInserter.java:105)
	at org.eclipse.jgit.api.CommitCommand.createTemporaryIndex(CommitCommand.java:366)
	at org.eclipse.jgit.api.CommitCommand.call(CommitCommand.java:195)
	... 8 more

$ git config -l

core.symlinks=false
core.autocrlf=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
diff.astextplain.textconv=astextplain
rebase.autosquash=true
user.email=stepper@esc-net.de
user.name=Eike Stepper
core.editor="C:\Program Files (x86)\IDM Computer Solutions\UltraEdit\Uedit32.exe"
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.url=ssh://estepper@git.eclipse.org/gitroot/cdo/cdo.git
branch.master.remote=origin
branch.master.merge=refs/heads/master
Comment 1 Robin Rosenberg CLA 2012-01-26 18:26:02 EST 
Workaround: http://egit.eclipse.org/r/#/c/4998/
Comment 2 Slavoj Pisek CLA 2012-02-22 07:40:55 EST 
Hi, when can I expect the workaround appears in nightly-builds.
The fact I cannot commit some files is really frustrating. thanks a lot.
Comment 3 Glen Ihrig CLA 2012-03-06 02:31:29 EST 
I have experienced this issue

Mac OS X 10.6.8
SpringSource Tool Suite 2.8.1 RELEASE
EGit 1.3.0.201202151440-r

It happened for me after renaming a project and carefully updating all affected files (several hundred files changed). After this large change, many packages in my project indicated not being tracked. They were decorated with the '?'. The error condition happened when attempting to commit or add from the project root folder.

The problem seems to be related to large amounts of data as Robin Rosenberg suggested.

I found two simple work-arounds that got me back into production:

1. Using EGit - Add files a few at a time.  I was able to commit all changes in a single pass after adding in small chunks.

2. Using Git - After tiring of many small 'Add to Index' cycles I opened the project root folder in a terminal and executed 

[code]git add .[/code]
Problem solved.
Comment 4 Markward Schubert CLA 2012-03-06 10:52:21 EST 
Having the same issue here:

Windows XP 32Bit

Eclipse Core: 3.8.0.v20110920-2042
Egit: 1.3.0.201202151440-r

I don't know if this is of any help, but I use GIT Bash in parallel on the same workspace.
Comment 5 Robin Rosenberg CLA 2012-03-07 01:18:06 EST 
https://git.eclipse.org/r/#/c/4998/ has been merged. Try the next nighly build.
Comment 6 Eike Stepper CLA 2012-03-21 06:52:46 EDT 
It still happens with JGit 2.0.0.201203181018 ;-(
Comment 7 Robin Rosenberg CLA 2012-03-21 18:27:10 EDT 
(In reply to comment #6)
> It still happens with JGit 2.0.0.201203181018 ;-(

Apparently the patch was was not just ugly, it
broke something.

-- robin
Comment 8 Marc Herbert CLA 2012-03-22 06:23:07 EDT 
core.autocrlf=false avoids the bug for me.

(messing with line endings is a bad idea anyway)
Comment 9 Eike Stepper CLA 2012-03-22 06:47:11 EDT 
(In reply to comment #8)
> core.autocrlf=false avoids the bug for me.

Thanks for the hint. But then I would probably end up with 6000 dirty files due to wrong line endings, again.

> (messing with line endings is a bad idea anyway)

I consider it a mess if I clone a repo and all files are dirty without me changing something.

Or am I missing something?
Comment 10 Marc Herbert CLA 2012-03-22 11:42:59 EDT 
> > core.autocrlf=false avoids the bug for me.
> Thanks for the hint. But then I would probably end up with 6000 dirty files due
> to wrong line endings, again.

I switched it back to false on a "live" clone and nothing happened. Was I lucky? It's easy enough to see for yourself: simply duplicate your whole project and try.


> I consider it a mess if I clone a repo and all files are dirty without me
> changing something.

"crlf = false" should certainly NOT be a problem as long as:
1. you clone from scratch and,
2. you restrict yourself to modern editors which show equal respect to all files whatever is their origin.


The whole idea of source control "fixing" line endings is a hack; avoid it for as long as you can.
Comment 11 Oliver Mannion CLA 2012-03-22 16:53:45 EDT 
*** Bug 375114 has been marked as a duplicate of this bug. ***
Comment 12 Robin Rosenberg CLA 2012-05-05 08:48:44 EDT 
Fixed in https://git.eclipse.org/r/#/c/5412/
Comment 13 Michael Vorburger CLA 2012-05-31 20:00:05 EDT 
I'm not sure how useful such "verification" feedback is, but.. I've just run into the exception above, on a 1.3.0, and I can confirm that upgrading to a nightly 2.0.0.20120531 did the magic - thanks!
Comment 14 Robin Stocker CLA 2012-08-08 14:05:33 EDT 
*** Bug 386868 has been marked as a duplicate of this bug. ***