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

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

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

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

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

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

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

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

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

См. Коммит 5bdece0 (15 декабря 2018 г.) Йоханнеса Шинделина ( 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 Jan 2016)}

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

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

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

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

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

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

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

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

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

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

В моем случае это было потому, что я запускал Git из командной строки без повышенных прав. «Запуск от имени администратора» исправил это для меня.

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

В Windows, использующей GitHub для Windows, я получил похожую ошибку в оболочке при запуске git gc:

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

Я решил это, закрыв графический интерфейс GitHub.

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

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

Закройте вашу IDE, затем сделайте git pull. Это сработает.

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

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

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

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

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

Unlocker

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

Возникновение залипания в цикле было очищено закрытием Git-GUI. (Я запускал git merge -i в оболочке bash.)

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

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

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

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

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

'git gc --force'

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

Попробуйте запустить редактор командной строки в административном режиме и выполните команду. Это помогает и решает проблему. :)

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

git config --global --unset remote.origin.fetch '\+refs/tags/\*:refs/tags/\*'

затем добавьте это, чтобы удалить удаленные ветви на сервере:

git config --global fetch.pruneTags true

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