힘내 '심각 : 새 색인 파일을 쓸 수 없습니다'

힘내 '심각 : 새 색인 파일을 쓸 수 없습니다'

---

나는 이것에 대한 많은 다른 스레드를 보았지만 도움이되지 않습니다.

두 개의 JavaScript 파일이라는 매우 간단한 저장소가 있습니다. Macbook에 100GB 이상이 있습니다. 파일을 하위 디렉토리로 이동하고 로컬에서 변경 사항을 준비하려고하면 ...

치명적 : 새 색인 파일을 쓸 수 없습니다.

이것은 터미널에서 모든 작업을 수행하거나 SourceTree와 같은 GUI를 사용하는 경우 발생합니다. 또한 파일 중 하나가 잠기고 로그 오프했다가 다시 로그인 할 때까지 작업 디렉터리를 삭제할 수 없습니다.

왜 이런 일이 발생합니까? 잠금으로 인해 스테이징을 방해합니까? 그렇다면 OS X에서 문제 파일을 어떻게 / 어떻게 잠금 해제합니까 ?? 원격 저장소는 Google 코드입니다. 차이가 있다면 아직 원격으로 푸시하지는 않습니다. 모든 것이 현지입니다.

---

제 경우에는 디스크 공간이 부족하여 공간을 확보하기 위해 하드 드라이브에서 파일을 삭제해야했습니다.

---

지난 며칠 동안 동일한 문제가 발생했습니다. 기본적으로 내 지식없이 전체 저장소가 새 파일 시스템으로 이동되었으며 git status를 실행하려고 할 때 저장소의 모든 파일이 업데이트되었다고 갑자기보고했습니다.

가능한 해결책

그래서 많은 Google 수색 후 다음을 시도했습니다.

• .git permssions 변경 (동일한 문제)
• .git / index 권한 변경 (동일한 문제)
• git add-ing all the changes to commit (동일한 문제)
• git rm-ing 파일 이름이 너무 긴 오류를보고했기 때문에 삭제 된 파일 (동일한 문제)
• git reset (soft | Head | Hard) (동일한 문제)
• git clean (동일한 문제)
• Windows 방어자 끄기 (동일한 문제)
• git 업데이트 (동일한 문제)
• 다른 git 클라이언트 (나는 gitbash 사용) (동일한 문제)
• 커피 1 잔 대신 2 잔 마시기 (동일한 문제)

tl : dr-더러운 솔루션

문제를 해결 한 유일한 방법은 색인 파일을 복사하고 원본을 삭제하고 사본의 이름을 바꾸는 것입니다.

나는 그것이 실제로 '솔루션'이 아니라는 것을 알고 있지만 이제는 모든 파일 / 브랜치를 그대로 유지하면서 마술처럼 작동합니다. 이것이 왜 효과가 있는지 아는 사람이 있다면 말하십시오.

---

Mac에서도 같은 문제가 발생했습니다. 파일 시스템 ACL로 인한 것 같습니다. 시도 chmod -RN /path/to/repoACL을 취소 할 수 있습니다. 이렇게 한 후 변경 사항을 적용 할 수있었습니다. 색인 파일을 복사하는 트릭을 사용하여 원본을 삭제하고 복사본을 다시 이동하면 동일한 결과를 얻었습니다.

---

Google 드라이브 또는 Dropbox와 같은 일종의 온라인 동기화 서비스에 github 설정이있는 경우 github가 동일한 작업을 수행하려고 할 때 동기화 서비스가 파일 읽기 / 쓰기를 시도하므로 동기화를 비활성화하면 github가 작동하지 않습니다. 바르게.

---

제 경우에는 Dropbox 동기화를 일시 중지하여 문제를 해결했습니다.

---

.git / index 파일이 다른 프로세스 (내 로컬 개발 웹 서버)에서 사용 중이라는 사실을 알게되었습니다. 프로세스를 종료 한 다음 작동했습니다.

---

이것은 나를 위해 일했습니다.

rm -f ./.git/index.lock

---

제 경우 솔루션은 새 사용자에게 권한을 추가하는 것뿐이었습니다.

새 OS를 설치하고 저장소를 옮겼을 때 정확한 오류가 표시되었습니다. 루트 폴더를 선택한 다음 사용자를 인증하여 모든 것을 확인했습니다.

---

.git 폴더의 모든 파일에 ACL (어쨌든)을 첨부했습니다.

ls -le.git 폴더에서 확인하십시오 .

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

---

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).

---

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

---

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.

---

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.

---

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

---

This issue may be caused by .git\index locked by a process.

The link Find out which process is locking a file or folder in Windows specifies the following approach to find a locked 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 should resolve the issue.

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

---

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

---

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

---

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.

---

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..!!

---

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 :).

---

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

---

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. :)

참고 URL : https://stackoverflow.com/questions/16064513/git-fatal-unable-to-write-new-index-file