Git 'фатальный: невозможно записать новый индексный файл'


128

Я видел много других веток об этом, и они не помогают.

У меня очень простое репо - два файла JavaScript. У меня на Macbook более 100 ГБ. Когда я пытаюсь переместить файлы в подкаталог и локально обрабатывать изменения, я получаю ...

фатальный: невозможно записать новый индексный файл

Это происходит независимо от того, выполняю ли я все действия в терминале или использую графический интерфейс, например SourceTree. Кроме того, один из файлов блокируется, и я не могу удалить рабочий каталог, пока не выйду из системы и не вернусь обратно.

Почему это происходит? Блокировка препятствует постановке чего-либо? Если да, то что / как мне разблокировать проблемный файл на OS X ?? Удаленное репо - это Google Code, если это имеет значение, хотя я еще не нажимаю на удаленный. Все местное.


Не уверены, что это должно перейти к SuperUser ?
MMM

скорее всего, проблема с правами доступа (у пользователя, запускающего git, нет прав на запись для всего
репозитория

Об этом есть темы в SO и SU. Я думаю, что вопрос работает одинаково хорошо в обоих случаях. Невик, права на репо 777, включая ./gitпапку.
Джефф

Когда вы видите эту проблему? Это когда вы выполняете «git mv» или «git add»?
Mayur Nagekar

Ответы:


222

В моем случае на диске закончилось место, поэтому мне пришлось удалить файлы с жесткого диска, чтобы освободить место.


64

У меня такая же проблема последние несколько дней. По сути, без моего ведома все репо было перемещено в новую файловую систему, когда я попытался запустить git status, он внезапно сообщил, что каждый файл в репо был обновлен.

Возможные решения

Итак, после долгого поиска в Google я попробовал следующее:

  • изменение разрешений .git (та же проблема)
  • изменение разрешений .git / index (та же проблема)
  • git добавляет все изменения для фиксации (та же проблема)
  • git rm-ing удалил файлы, так как они сообщали об ошибках слишком длинного имени файла (та же проблема)
  • git reset (soft | Head | Hard) (та же проблема)
  • git clean (та же проблема)
  • отключение защитника Windows (та же проблема)
  • обновление git (та же проблема)
  • разные клиенты git (я использую gitbash) (та же проблема)
  • выпить 2 чашки кофе вместо 1 (та же проблема)

tl: dr - грязное решение

Единственное, что удалось решить - скопировать индексный файл, удалить оригинал и переименовать копию.

Я знаю, что это не совсем «решение», но теперь он волшебным образом работает> <, со всеми файлами / ветвями нетронутыми. Если кто знает, почему это могло работать, расскажите.


82
Обнаружена еще одна причина: возможно, вам не хватает места на диске.
lennartcl

21
В моем случае Google Диск загружал (резервное копирование) файлов, и они были заблокированы во время процесса. После завершения загрузки коммит заработал.
Кристьян О.

3
Спасибо за подсказку о Google Диске. У меня была такая же проблема, но с Dropbox.
hgolov

1
Перезагрузка у меня сработала. Работает на полупустом общем диске 22 ТБ, поэтому места не было проблемой.
Уэйн Ф. Каски

1
ваше «грязное решение» сработало для меня (возвращено в предыдущий индексный файл, повторно добавлено и повторно зафиксировано все изменения с тех пор)
trust_words

19

В моем случае приостановка синхронизации Dropbox решила проблему


17

У меня была такая же проблема на Mac. Похоже, это вызвано ACL файловой системы. Попробуйте chmod -RN /path/to/repoочистить ACL. После этого я смог зафиксировать изменения. Используя трюк, чтобы скопировать индексный файл, удалить оригинал и переместить копию назад, вы получили тот же результат.


Если ваша учетная запись пользователя недавно имела какие-либо проблемы с разрешениями, это могло привести к возникновению этой проблемы. В моем случае проблема с интеграцией с Active Directory оставила у меня проблемные ACL.
Крис

17

Если у вас есть настройка github в какой-то онлайн-службе синхронизации, такой как google drive или dropbox, попробуйте отключить синхронизацию, поскольку служба синхронизации пытается читать / писать в файл, поскольку github пытается сделать то же самое, что приводит к тому, что github не работает правильно.


Это решение, которое сработало для меня. Спасибо!
Макондо,

7

Со мной случилось так, что файл .git / index использовался другим процессом (моим локальным веб-сервером разработки). Я остановил процесс, и все заработало.


7

Закрытие кода Visual Studio (которое в моем случае имеет фоновое задание автозагрузки, выполняющееся при сохранении файла) решило проблему для меня.

Благодарим за решение: мой друг и коллега Арнел.


Я закрыл сервер nodeJs, на котором работало мое приложение angularJs, и индекс был разблокирован
Раду Лину,


6

В моем случае решением было только добавление разрешения новому пользователю.

Когда я установил новую ОС, переместил свои репозитории и показывал именно эту ошибку, я выбрал корневую папку, а затем добавил аутентифицированного пользователя, чтобы проверить все введите описание изображения здесь


3

У меня был ACL (каким-то образом), прикрепленный ко всем файлам в папке .git.

Проверьте это ls -leв папке .git.

Вы можете удалить ACL с помощью chmod -N(для папки / файла) или chmod -RN(рекурсивно)


3

Я думаю, что некоторые фоновые решения для резервного копирования, такие как Google Backup и Sync, блокируют доступ к индексному файлу. Я закрыл приложение, и у Sourcetree не было никаких проблем. Похоже, Dropbox делает то же самое (@tonymayoral).


2

В моем случае это был одновременный запуск EGit. После перезапуска eclipse все работает как обычно.


вопрос: почему появляется сообщение об ошибке? и этот ответ описывает другую потенциальную причину.
robm

2

Если вы используете Windows, убедитесь, что программа, которую вы используете, будь то исходное дерево или терминал git, запущена от имени администратора. Я получал такое же точное сообщение об ошибке. Вы можете либо щелкнуть правой кнопкой мыши программу, чтобы запустить ее от имени администратора, либо изменить ее свойства, чтобы всегда запускать от имени администратора.



2

У меня такая же проблема. Я перезапустил свой компьютер, и проблема была решена.


1

вы пробовали "git add". , это все изменится? (вы можете удалить ненужные добавленные файлы с помощью git reset HEAD)


1

Это сообщение об ошибке fatal: Unable to write new index fileозначает , что мы не могли написать новое содержимое в файл индекс мерзавца .git\index(см здесь для получения дополнительной информации о индексе мерзавца). Изучив все ответы на этот вопрос, я резюмирую следующие основные причины:

  • Размер нового содержимого превышает доступную емкость диска. ( Решение : очистите дисковое пространство)
  • У пользователей нет прав доступа к этому файлу. ( Решение : дайте разрешение)
  • У пользователей есть разрешение, но они .git\indexзаблокированы другими пользователями или процессами. ( Решение : разблокировать файл)

Ссылка Узнать, какой процесс блокирует файл или папку в Windows, указывает следующий подход для определения процесса, блокирующего конкретный файл:

SysInternals Process Explorer - выберите «Найти»> «Найти дескриптор» или «DLL». В текстовом поле «Обработка или подстрока DLL:» введите путь к файлу (например, «C: \ path \ to \ file.txt») и нажмите «Поиск». Должны быть перечислены все процессы, у которых есть открытый дескриптор этого файла.

Используйте описанный выше подход, чтобы определить, какой процесс заблокирован, .git\indexа затем остановить исполняемый файл блокировки. Это разблокирует .git\index.

Например, поиск в Process Explorer показывает, что .git\indexзаблокирован vmware-vmx.exe. Приостановка виртуальной машины VMWare Player (которая обращалась к репозиторию git через общую папку) решила проблему.


Хотя эта ссылка может дать ответ на вопрос, лучше включить сюда основные части ответа и предоставить ссылку для справки. Ответы, содержащие только ссылки, могут стать недействительными, если ссылка на страницу изменится. - Из
отзыва

@Al, я обновил свой ответ в соответствии с вашим предложением.
Fan,

0

ЕСЛИ ВЫ ПОЛУЧИТЕ ЭТО ВО ВРЕМЯ ПЕРЕБАЗЫ:

Скорее всего, это вызвано тем, что какое-то программное обеспечение блокирует индексный файл вашего репо, например программное обеспечение для резервного копирования, антивирусы, IDE или другие клиенты git.

В большинстве случаев блокировка бывает кратковременной, и это происходит просто из-за неудачного выбора времени.

Однако git rebase --continueбудет жаловаться на то, что следующая команда является пустой фиксацией:

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

    git commit --allow-empty

Чтобы исправить это, просто запустите git resetи попробуйте еще git rebase --continueраз.


0

Проблема: когда я проверял некоторые измененные файлы в git, я получил эту ошибку. У меня было два пользователя ABC и XYZ. файлы имеют uid: gid ABC, но у него нет доступа к git и он пытается проверить файлы с тем же.

Решение, которое я пробовал: XYZ имеет доступ к git, попытался проверить файлы с помощью sudo, и это сработало .. !!


0

Вот что у меня сработало:

Контекст:

  1. Сборка проекта на сервере

  2. git status возвращает HEAD detached at <commit-SHA>

  3. Какую бы операцию я ни делал локально, у меня была эта ошибка. Более конкретно:

    • git checkout
    • git reset HEAD --hard

Решение

  1. Просто удаленный файл <work-dir>/.git/index .
  2. А git statusозначает, что все файлы в проекте не отслеживаются (здесь нет ничего удивительного).
  3. git reset HEAD --hard
  4. Вернемся к тому, HEAD detached at <commit-SHA>когда вы делаете git status, но тогда вы сможете
  5. git checkout <some-branch>

и вы снова на правильном пути!

!! ВАЖНЫЙ !!

Это работает только потому, что я «веселый» строю. Никаких важных изменений в коде не производилось. Если вы на самом деле находитесь в «режиме разработки», то я бы порекомендовал сначала сохранить вашу работу или выбрать другой метод.

Надеюсь, это поможет :).


0

У меня была эта проблема с использованием GitExtensions в Windows. Исправлено предоставлением текущему пользователю (мне) полного разрешения на папку, содержащую репо.

В другой раз, хотя я получал ошибку от Git Extensions, я смог зафиксировать те же файлы из Visual Studio 2015.

В другой раз мне пришлось удалить "индексный" файл из папки .git


0

Мой случай немного интересен:

Я запускаю git log, чтобы проверить определенную фиксацию, затем я не вышел из нее должным образом, я нажимаю ctrl + c, чтобы выйти из нее.

Тогда индекс кажется заблокированным. Поэтому я снова запускаю git log и нажимаю Q, чтобы выйти.

Проблема исправлена. :)


Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.