Unlink файла не удалось

152

Я пытаюсь сделать git pull, и я получаю следующую ошибку:

Не удалось удалить ссылку "lib/xxx.jar". Должен ли я повторить попытку? (Г/л)

Независимо от того, выбираю ли я y или n, невозможно добраться до состояния, в котором я могу вытащить или надавить.

  • 0
    Вы проверяли, есть ли у вас права на запись в этот файл?
  • 1
    запустите правильный chmod и / или chown для указанного файла.
Показать ещё 7 комментариев
Теги:

14 ответов

200
Лучший ответ

Это обычно означает, что процесс все еще использует этот конкретный файл (все еще имеет дескриптор)
(в Windows ProcessExplorer хорошо отслеживает такие процессы)

Попробуйте закрыть другие программы и попробуйте еще раз ваш git pull.

Обратите внимание, что у вас есть альтернатива с переменной GIT_ASK_YESNO.

Обновление января 2019 года:

Это должно быть еще более исправлено, с Git 2.21 (Q1 2019), так как " git gc " и " git repack " не закрывали открытые файлы пакета, которые были сочтены ненужными перед их удалением, которые не работали на платформе, неспособной удалить открытый файл.
Это было исправлено.

См. Коммит 5bdece0 (15 декабря 2018 г.) Йоханнеса dscho (dscho).
(Объединено Junio C Hamano - gitster - в коммите 5104f8f, 18 января 2019 г.)

gc/repack: выпускать пакеты при необходимости

В Windows файлы не могут быть удалены или переименованы, если все еще есть дескрипторы, удерживаемые процессом.
Чтобы исправить это, мы ввели close_all_packs().

Ранее мы убедились, что пакеты выпускаются непосредственно перед порождением git gc, на случай, если gc захочет удалить ненужные пакеты.

Но этот разработчик забыл, что сам gc также должен выпускать пакеты, например, при объединении всех пакетов с помощью опции --aggressive.

Аналогично, git repack -d хочет удалить устаревшие пакеты и, следовательно, должен также закрыть все дескрипторы пакетов.

Обновление январь 2016

Это должно быть исправлено в Git 2.8 (март 2016 г.) (и см. Git 2.19, Q3 2018 ниже)

См. Коммит d562102, коммит dcacb1b, коммит df617b5, коммит 0898c96 (13 января 2016 г.) от Johannes Schindelin (dscho).
(Объединено Junio C Hamano - gitster - в коммите 3c80940, 26 января 2016 г.)

fetch: выпустить файлы пакета перед сборкой мусора

Перед автоматическим сбором файлов мы должны убедиться, что файлы пакетов выпущены на тот случай, если их нужно перепаковать и собрать мусор.

Многие пути кода, которые запускают " gc --auto " перед выходом, сохраняют сопоставленные файлы пакета и оставляют дескрипторы файлов открытыми, что не подходит для систем, которые не могут удалить открытые файлы.
Теперь они закрывают пакеты, прежде чем сделать это.

Это исправляет проблему 500 git-for-widows.

Если посмотреть на тест, используемый для проверки этого нового подхода, возможный обходной путь (поскольку Git 2.8 еще не gc.autoPackLimit) заключается в искусственном повышении gc.autoPackLimit.

git config gc.autoPackLimit 10000
git fetch
git config gc.autoPackLimit 50 # default value

В git 2.8.4 (июнь 2016 г.) упоминается проблема 755, которая также должна облегчить проблему (commit 2db0641):

Убедитесь, что дескрипторы временных файлов не наследуются дочерними процессами

На самом деле, упомянутая выше проблема 500 git-for-windows действительно исправлена в Git 2.19, Q3 2018.
См. " Git - сбой связи файлов .idx и .pack (единственный дескриптор этого файла принадлежит git.exe) "

Поделиться
  • 5
    Скорее всего, JVM работает с использованием этого jar-файла.
  • 2
    В моем случае это был скайп. Ранее я передавал файл другим, а некоторые еще не приняли или не отменили.
Показать ещё 7 комментариев
51

Это ответ на конкретный Windows, поэтому я знаю, что это не относится к вам... Я просто включаю его в интересах будущих поисковиков.

В моем случае это произошло из-за того, что я запускал Git из невыполненной командной строки. "Запуск от имени администратора" исправил его для меня.

Поделиться
  • 4
    Я столкнулся с этой проблемой в Windows 7, когда выполнял pull, а git делал auto pack. Он жаловался на файлы "idx". Затем я открыл окно консоли в качестве администратора и запустил git gc, и проблем не было. Так что это хорошее решение.
  • 1
    git gc сделал это для меня в Windows 7. Это произошло, потому что я делал git pull для cmder, одновременно нажимая на WebStorm
Показать ещё 3 комментария
23

Для меня это потому, что Visual Studio пыталась перезагрузить все измененные файлы из pull. Обновите визуальную студию, затем запустите git gc.

Поделиться
  • 3
    Похоже на меня. Eclipse нужно было закрыть перед запуском git gc.
  • 3
    git gc похоже, также работает для меня
Показать ещё 1 комментарий
5

В Windows с использованием GitHub для Windows я получил аналогичную ошибку в оболочке при запуске git gc:

Unlink of file '.git/objects/pack/pack-0b40ae7eae9b83edac62e19c07ff7b4c175244f6.idx' failed. Should I try again? (y/n)

Я решил это, закрыв GUI GitHub.

Поделиться
2

Закройте свою среду IDE, затем выполните git pull. Это будет работать.

Поделиться
2

Закрыл Visual Studio и Rubymine и не получил ошибку снова. Один из них был виновником.

Поделиться
2

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

Поделиться
  • 0
    Ага. Остановка Tomcat решила проблему для меня.
1

Это было вызвано в моем случае SimpLESS, компилятором LESS. Вы должны закрыть его в systray.

Поделиться
0

Ни один из приведенных выше ответов не работает для меня, но я запускаю команду git gc с параметром force, и это решает мою проблему.

'git gc --force'

[Windows 7, Запуск от имени администратора => Командная строка]

Поделиться
0

У меня была такая же проблема, и я закрыл все связанные программы из Window Task Manager. Однако он все еще не работал. Интересная часть состоит в том, что я запускал "Git rebase" вместо "Git pull", и это сработало!

Поделиться
0

У меня был PHPStorm открытый, закрытый, и все было хорошо.

Поделиться
0

У меня это произошло в Windows XP, как с сообщением, застрявшим в цикле, так и с возможностью очистки путем ответа.

Зафиксированное вхождение было очищено закрытием Git -GUI. (Я запускал git merge -i в оболочке bash.)

Другие события произошли, возможно, из-за большого количества файлов в моем репозитории. Это произошло в основном с файлами .cod, которые я позже исключаю из контроля версий. (У меня есть причина для их отслеживания.) Я полагаю, что причина может быть связана со скоростью, с которой git использует дескрипторы файлов.

Интересно, связана ли проблема с способностью к очистке от ответа, связанная с Windows, поскольку два предыдущих плаката упомянули Windows, и никто не сказал, что у них есть проблема с другими операционными системами.

Поделиться
0

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

Unlocker

Поделиться
0

У меня тоже есть эта проблема, но я узнал, что это был UltraEdit на этом пути, так как я использовал UE для организации и редактирования рабочей области eclipse ~~

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

После того, как я закрыл UltraEdit, проблема больше не повторялась.

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню