Git 'fatal: Unable to write new index file'

问题

I've seen many of the other threads about this and they don't help.

I have a very simple repo - two JavaScript files. I have 100+ GB on Macbook. When I try to move the files into a subdirectory and stage locally the changes I get ...

fatal: Unable to write new index file

This happens whether I do all actions in terminal or if I use a GUI like SourceTree. Additionally, one of the files becomes locked and I cannot delete the working directory until I log off and back in.

Why is this happening? Is the lock preventing something from staging? If so, what/how do I unlock the problem file on OS X?? The remote repo is Google Code, if that makes a difference, though I am not pushing to the remote yet. Everything is local.

回答1:

In my case, the disk ran out of space, so I had to delete files from the hard drive to make space.

回答2:

I've been having this same problem for the last few days. Basically, without my knowledge the entire repo had been moved to a new filesystem, when I tried to run git status, it was suddenly reporting that every file in the repo had been udpated.

Possible solutions

So, after much google scouring, I tried the following:

• changing .git permssions (same issue)
• changing .git/index permissions (same issue)
• git add-ing all the changes to commit (same issue)
• git rm-ing deleted files, since they were reporting file name too long errors (same issue)
• git reset (soft|Head|Hard) (same issue)
• git clean (same issue)
• turning off windows defender (same issue)
• updating git (same issue)
• different git clients (i use gitbash) (same issue)
• drinking 2 coffees instead of 1 (same issue)

tl:dr - dirty solution

The only thing that managed to solve the issue was to copy the index file, delete the original and rename the copy.

I know its not really a 'solution' but now its magically working ><, with all files / branches intact. If anyone knows why this might have work, do tell.

回答3:

I had the same issue on a Mac. It seems to be caused by filesystem ACLs. Try chmod -RN /path/to/repo to clear the ACLs. After doing this I was able to commit changes. Using the trick to copy the index file, delete the original and move the copy back achieved the same result.

回答4:

If you have your github setup in some sort of online syncing service, such as google drive or dropbox, try disabling the syncing as the syncing service tries to read/write to the file as github tries to do the same, leading to github not working correctly.

回答5:

In my case, pausing dropbox sync solved the issue

回答6:

It happened to me that the file .git/index was in use by another process (my local development web server). I shut down the process and then it worked.

回答7:

This worked for me:

rm -f ./.git/index.lock

回答8:

In my case, the solution was only adding permission to the new user.

When I installed new OS, moved my repos around and it was showing this exact error I selected the root folder and then added authenticated the user to check all

回答9:

I had ACL (somehow) attached to all files in the .git folder.

Check it with ls -le in the .git folder.

You can remove the ACL with chmod -N (for a folder/file) or chmod -RN (recursive)

回答10:

Closing Visual Studio Code (that in my case has an auto-uploader background job running on file-save) solved the issue for me.

Credit for the solution: my friend and colleague Arnel.

回答11:

I think some background backup solutions like Google Backup and Sync block access to the index file. I closed the application and Sourcetree had no issues at all. Seems that Dropbox does the same (@tonymayoral).

回答12:

In my case it was a concurrent running EGit. After restarting eclipse it works as usual.

回答13:

If you're on a Windows box, make sure the program you're using, whether it's Source Tree or a git terminal, is running as administrator. I was getting the same exact error message. You can either right click on the program to run as administrator or change its properties to always run as administrator.

回答14:

I had the same problem. I restarted my computer and the issue was resolved.

回答15:

did you try 'git add .' . will it all the changes? (you can remove unnecessary added files by git reset HEAD )

回答16:

Not having enough space is an issue. Cleanup and try again

回答17:

The error message fatal: Unable to write new index file means that we could not write the new content to the git index file .git\index (See here for more information about git index). After reviewing all the answers to this question, I summarize the following root causes:

• The size of new content exceeds the disk available capacity. (Solution: Clean the disk spaces)
• Users do not have access right to this file. (Solution: Grant the permission)
• Users have permission but .git\index is locked by other users or processes. (Solution: Unlock the file)

The link Find out which process is locking a file or folder in Windows specifies the following approach to find out the process which is locking a specific file:

SysInternals Process Explorer - Go to Find > Find Handle or DLL. In the "Handle or DLL substring:" text box, type the path to the file (e.g. "C:\path\to\file.txt") and click "Search". All processes which have an open handle to that file should be listed.

Use the above approach to find which process locked .git\index and then stop the locking executable. This unlocks .git\index.

For example, Process Explorer Search shows that .git\index is locked by vmware-vmx.exe. Suspending the VMWare Player virtual machine (which accessed the git repo via a shared folder) solved the issue.

回答18:

IF YOU GET THIS DURING A REBASE:

This is most likely caused by some software locking the index file of your repo, such as backup software, anti-viruses, IDEs or other git clients.

In most cases the lock is just for a brief moment and so it just happens out of bad-timing and bad luck.

However, git rebase --continue will complain about the next command being an empty commit:

The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

To fix this, just run git reset and try git rebase --continue again.

回答19:

Issue: When I was checking out some modified files in git, got this error. I was having two users ABC and XYZ. files are having uid:gid of ABC but it doesn't have git access and trying to checkout the files with same.

The solution I have tried: XYZ is having git access, tried checking out files with sudo and it worked..!!

回答20:

Here is what worked for me:

Context:

1. Building a project on a server

2. git status returns a HEAD detached at <commit-SHA>

3. What ever operation I did locally, I had this error. More specifically:

   • git checkout
   • git reset HEAD --hard

Solution

1. Simply removed file <work-dir>/.git/index.
2. A git status would indicate that all files in the projet are not tracked (no surprise here).
3. git reset HEAD --hard
4. Back to HEAD detached at <commit-SHA> when doing a git status, but then you should be able to
5. git checkout <some-branch>

and you're back on track!

!! IMPORTANT !!

This works only because I am "merly" building. No precious modification has been performed on the code. If you are actually in "dev-time", then I would recommand to save your work first or go for another method.

Hope it will help :).

回答21:

I had this problem using GitExtensions on windows. Fixed by granting full permission for the current user (me) on the folder that contained the repo.

Another time, I even though I was getting the error from Git Extensions, I was able to commit the same files from Visual Studio 2015.

Another time I had to delete the "index" file from the .git folder

回答22:

My case is a bit interesting:

I run git log to check a certain commit, then I didn't quit it properly, I press ctrl+c to exit it.

Then the index seems been locked. So I run git log again, then press Q to quit it.

Problem fixed. :)

来源：https://stackoverflow.com/questions/16064513/git-fatal-unable-to-write-new-index-file