Falha ao desvincular do arquivo


169

Estou tentando fazer um git pull e recebo o seguinte erro:

Falha ao desvincular o arquivo 'lib / xxx.jar'. Devo tentar novamente? (s / n)

Não importa se eu selecionar y ou n, não é possível chegar a um estado em que eu possa puxar ou empurrar.


Você verificou se tem o direito de gravar nesse arquivo?
Raphael Michel

1
execute o direito chmode / ou chownno arquivo mencionado.
#

Eu deveria ter os direitos, caso contrário eu vou chown / chmod-lo!
Marko


1
Possível duplicata do rebase
aneroid

Respostas:


204

Isso geralmente significa que um processo ainda está usando esse arquivo específico (ainda tem um identificador)
(no Windows, ProcessExploreré bom em rastrear esse tipo de processo)

Tente fechar seus outros programas e tente novamente o seu git pull.

Note-se que você tem uma alternativa com a GIT_ASK_YESNOvariável .


Atualize janeiro de 2019:

Isso deve ser ainda mais corrigido, com o Git 2.21 (primeiro trimestre de 2019), pois " git gc" e " git repack" não fecharam os arquivos de pacotes abertos que consideravam desnecessários antes de removê-los, o que não funcionava em uma plataforma incapaz de remover um arquivo aberto.
Isso foi corrigido.

Veja commit 5bdece0 (15 Dec 2018) por Johannes Schindelin ( dscho) .
(Mesclado por Junio ​​C Hamano - gitster- in commit 5104f8f , 18 jan 2019)

gc/repack : libera pacotes quando necessário

No Windows, os arquivos não podem ser removidos nem renomeados se ainda houver identificadores retidos por um processo.
Para remediar isso, introduzimos oclose_all_packs() função

Anteriormente, garantimos que os pacotes fossem liberados logo antes da git gcgeração, caso issogc deseje remover os pacotes que não são mais necessários.

Mas esse desenvolvedor esqueceu que gctambém precisa liberar pacotes, por exemplo, ao consolidar todos os pacotes via--aggressive opção.

Da mesma forma, git repack -ddeseja excluir pacotes obsoletos e, portanto, também precisa fechar todos os identificadores de pacote.


Atualização de janeiro de 2016

Isso deve ser corrigido no Git 2.8 (março de 2016) (e veja Git 2.19, terceiro trimestre de 2018 abaixo)

Consulte commit d562102 , commit dcacb1b , commit df617b5 , commit 0898c96 (13 de janeiro de 2016) por Johannes Schindelin ( dscho) .
(Mesclado por Junio ​​C Hamano - gitster- na confirmação 3c80940 , 26 de janeiro de 2016)

fetch: libere arquivos do pacote antes da coleta de lixo

Antes de fazer o gc'ing automático, precisamos garantir que os arquivos do pacote sejam liberados, caso precisem ser reembalados e coletados no lixo.

Muitos caminhos de código que " gc --auto" executam antes de sair mantinham os arquivos de pacotes mapeados e deixaram os descritores de arquivos abertos para eles, o que não era amigável para sistemas que não podem remover arquivos abertos.
Eles agora fecham os pacotes antes de fazê-lo.

Isso corrige o git-for-widowsproblema 500 .

Observando o teste usado para validar essa nova abordagem , uma possível solução alternativa (desde que o Git 2.8 ainda não foi lançado) seria aumentar artificialmente gc.autoPackLimit.

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

O git 2.8.4 (junho de 2016) menciona o problema 755, que também deve aliviar o problema ( commit 2db0641 ):

Verifique se os identificadores de arquivo temporário não são herdados pelos processos filho


Na verdade, o git-for-windowsproblema 500 mencionado acima foi realmente corrigido com o Git 2.19, terceiro trimestre de 2018.
Consulte " Git - Desvinculação do arquivo .idxe .packfalha (o único processo de propriedade desse arquivo é git.exe) "


5
Provavelmente, há uma JVM em execução usando esse arquivo jar.
Thorbjørn Ravn Andersen

2
No meu caso, era o Skype. Eu já havia transferido o arquivo para outras pessoas e algumas ainda não haviam aceitado ou cancelado.
Vivek Kodira

6
Eu achei o Windows Explorer o culpado. Provavelmente, devido às sobreposições de ícones do TortoiseGit ou ao TGitCache. Fechar todas as pastas abertas fez o truque, mas talvez você precise fechar a pasta do projeto se ela estiver aberta.
Allan Bogh

4
No meu caso, era o VS2013, pois estava vinculado à solução aberta.
BrotherOdin

2
Explorer.exe foi o meu problema - não tenho o TortoiseGit. Eu matei explorer.exe do Gerenciador de tarefas e gerou um novo usando CTRL-Alt-Delete => Task Manager => File => Run New Task => "explorer.exe" (sem as aspas)
joehanna

57

Esta é uma resposta específica do Windows, por isso estou ciente de que não é relevante para você ... Estou apenas incluindo-a para o benefício de futuros pesquisadores.

No meu caso, foi porque eu estava executando o Git a partir de uma linha de comando não elevada. "Executar como administrador" corrigiu para mim.


4
Eu atingi esse problema no Windows 7 ao fazer um pull e git fez um pacote automático. Ele reclamou dos arquivos "idx". Abri uma janela do console como administrador e executei um git gc e não havia nenhum problema. Portanto, esta é uma boa solução.
grahamesd

1
git gc fez isso por mim no Windows 7. Isso aconteceu b / c eu estava fazendo um git pull em cmder ao fazer um empurrão no WebStorm
Alessandro

2
Uau. Obrigado NeilD. Também foi corrigido para mim. Seria bom portar o GIT para o Windows um pouco mais.
Martin Dobšík 30/03

Bem ... isso foi necessário há 6 anos. Agora? Quem sabe? ¯_ (ツ) _ / ¯
NeilD

30

Para mim, foi porque o Visual Studio estava tentando recarregar todos os arquivos alterados a partir do pull. Faça a atualização do visual studio e execute git gc.


3
Semelhante para mim. O Eclipse precisava ser fechado antes de executar o git gc.
Alfoks

5

No Windows usando o GitHub para Windows, recebi um erro semelhante no shell ao executar git gc:

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

Eu o resolvi fechando a GUI do GitHub.


2

Tente reiniciar o Apache ou outro servidor da Web, pois pode ter bloqueado alguns de seus arquivos.


2

Fechou o Visual Studio e Rubymine e não recebeu o erro novamente. Um deles foi o culpado.



1

Também tenho esse problema, mas descobri que era o UltraEdit, pois usei o UE para organizar e editar minha área de trabalho do eclipse ~~

Talvez porque o UE tenha um controle sobre a versão antiga de um arquivo específico, o Git não possa desvinculá-lo.

Depois que fechei o UltraEdit, o problema nunca mais aconteceu.


1

Isso foi causado no meu caso pelo SimpLESS, o compilador LESS. Você precisa fechá-lo na bandeja.


0

O problema é porque você está tendo algum programa que manipula esses arquivos. Tenho uma sugestão de que você deve usar o Unlocker para encontrar o programa que está lidando com ele:

destravador


0

Isso aconteceu no Windows XP, com a mensagem presa em um loop e com a possibilidade de ser limpo respondendo.

A ocorrência presa em um loop foi eliminada fechando a Git-GUI. (Eu estava executando o git merge -i em um shell bash.)

As outras ocorrências ocorreram possivelmente devido ao grande número de arquivos no meu repositório. Isso aconteceu principalmente com arquivos .cod, que depois excluo do controle de versão. (Eu tenho um motivo para rastreá-los inicialmente.) Acredito que a causa possa estar relacionada à taxa na qual o Git usa identificadores de arquivo.

Gostaria de saber se o problema que pode ser resolvido pela resposta está relacionado ao Windows, como dois pôsteres anteriores mencionaram o Windows e ninguém disse que tem o problema com outros sistemas operacionais.


0

Eu tinha o PHPStorm aberto, fechei isso e estava tudo bem.


0

Eu tive o mesmo problema e fechei todos os programas relacionados do Window Task Manager. No entanto, ainda não estava funcionando. A parte interessante é que eu executei "Git rebase" em vez de "Git pull" e funcionou!


0

Nenhuma das respostas acima não funciona para mim, mas eu executo o comando git gc com a opção force, e isso resolveu o meu caso.

'git gc --force'

[Windows 7, Executar como administrador => Prompt de comando]


0

Tente executar o editor de linha de comando no modo administrativo e execute o comando. Ajuda e resolve o problema. :)


0

No meu caso, eu tinha um método antigo de remoção de tags que estavam causando o problema. Eu o resolvi desabilitando o original:

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

Em seguida, adicione isso para remover ramificações excluídas no servidor:

git config --global fetch.pruneTags true

0

Eu enfrentei o mesmo erro e o resolvi fechando o eclipse e puxando novamente enquanto o arquivo estava sendo usado.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.