Nie udało się odłączyć pliku

Próbuję wykonać git pull i pojawia się następujący błąd:

Odłączenie pliku „lib / xxx.jar” nie powiodło się. Powinienem spróbować ponownie? (t / n)

Bez względu na to, czy wybiorę t czy n, nie jest możliwe osiągnięcie stanu, w którym mogę ciągnąć lub pchać.

Zwykle oznacza to, że proces nadal używa tego konkretnego pliku (nadal ma do niego uchwyt)
(w systemie WindowsProcessExplorer jest dobry w śledzeniu tego rodzaju procesu)

Spróbuj zamknąć inne programy i spróbuj ponownie git pull.

Zauważ, że masz alternatywę ze GIT_ASK_YESNOzmienną .

Aktualizacja styczeń 2019:

To powinno być jeszcze bardziej naprawione dzięki Git 2.21 (Q1 2019), ponieważ „ git gc” i „ git repack” nie zamykały otwartych plików paczek, które uznali za niepotrzebne przed ich usunięciem, co nie działało na platformie niezdolnej do usunięcia otwartego pliku.
Zostało to poprawione.

Zobacz commit 5bdece0 (15 grudnia 2018) autorstwa Johannesa Schindelina ( dscho) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zatwierdzeniu 5104f8f , 18 stycznia 2019 r.)}

gc/ repack: zwalniaj pakiety, gdy są potrzebne

W systemie Windows plików nie można usunąć ani zmienić ich nazw, jeśli nadal istnieją uchwyty utrzymywane przez proces.
Aby temu zaradzić, wprowadziliśmy close_all_packs()funkcję.

Wcześniej upewniliśmy się, że paczki są wydawane tuż przed git gcspawnowaniem, na wypadek gdyby tak byłogc ktoś chciał usunąć niepotrzebne już paczki.

Ale ten programista zapomniał, że gcsam również musi puścić paczki, np. Podczas konsolidacji wszystkich paczek za pośrednictwem--aggressive opcji.

Podobnie git repack -dchce usunąć przestarzałe paczki i dlatego też musi zamknąć wszystkie uchwyty paczek.

Aktualizacja styczeń 2016

Powinno to zostać naprawione w Git 2.8 (marzec 2016) (i zobacz Git 2.19, Q3 2018 poniżej)

Zobacz: commit d562102 , commit dcacb1b , commit df617b5 , commit 0898c96 (13 stycznia 2016) autorstwa Johannesa Schindelina ( dscho) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zatwierdzeniu 3c80940 , 26 stycznia 2016 r.)}

fetch: wypuść pliki paczek przed zbieraniem śmieci

Przed automatycznym gc'owaniem musimy się upewnić, że pliki paczek są zwolnione na wypadek, gdyby trzeba je było przepakować i zebrać jako śmieci.

Wiele ścieżek kodowych, które są uruchamiane gc --autoprzed zamknięciem " ", zachowywało mapowanie plików pakietów i pozostawiało otwarte deskryptory plików, co nie było przyjazne dla systemów, które nie mogą usunąć otwartych plików.
Teraz zamykają paczki, zanim to zrobią.

To rozwiązuje git-for-widowsproblem 500 .

Patrząc na test użyty do zweryfikowania tego nowego podejścia , możliwym obejściem (ponieważ Git 2.8 nie jest jeszcze dostępny) byłoby sztuczne podniesienie gc.autoPackLimit.

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

git 2.8.4 (czerwiec 2016) nie wspomina o problemie 755, który również powinien złagodzić ten problem ( zatwierdzenie 2db0641 ):

Upewnij się, że uchwyty plików tymczasowych nie są dziedziczone przez procesy potomne

W rzeczywistości wspomniany powyżej git-for-windowsproblem 500 został naprawiony w Git 2.19, trzeci kwartał 2018 r.
Zobacz „ Git - odłączenie pliku .idxi .packniepowodzenie (Jedynym uchwytem do tego pliku jest proces git.exe) ”.

To jest odpowiedź specyficzna dla systemu Windows, więc zdaję sobie sprawę, że nie jest ona dla Ciebie istotna ... Dołączam ją tylko dla przyszłych wyszukiwarek.

W moim przypadku było tak, ponieważ uruchamiałem Git z wiersza poleceń bez podwyższonych uprawnień. „Uruchom jako administrator” naprawił to za mnie.

Dla mnie było to spowodowane tym, że program Visual Studio próbował ponownie załadować wszystkie zmienione pliki z pull. Odśwież Visual Studio, a następnie uruchom git gc.

W systemie Windows korzystającym z GitHub dla Windows otrzymałem podobny błąd w powłoce podczas uruchamiania git gc:

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

Rozwiązałem to, zamykając GUI GitHub.

Spróbuj ponownie uruchomić Apache lub inny serwer WWW, ponieważ mógł zablokować niektóre pliki.

Zamknięto program Visual Studio i Rubymine i ponownie nie wystąpił błąd. Jeden z nich był winowajcą.

Zamknij IDE, a następnie zrób git pull. To będzie działać.

Mam też ten problem, ale dowiedziałem się, że to UltraEdit w drodze, ponieważ użyłem UE do organizowania i edytowania mojego obszaru roboczego zaćmienia ~~

Może dlatego, że UE ma uchwyt na starą wersję konkretnego pliku, Git nie mógł go odłączyć.

Po zamknięciu UltraEdit problem nigdy się nie powtórzył.

W moim przypadku było to spowodowane kompilatorem SimpLESS, LESS. Musisz go zamknąć w zasobniku systemowym.

Problem polega na tym, że masz program obsługujący te pliki. Mam sugestię, że powinieneś użyć Unlockera, aby znaleźć program, który go obsługuje:

Unlocker

Zdarzyło mi się to w systemie Windows XP, zarówno z komunikatem, który utknął w pętli, jak i można było go wyczyścić, odpowiadając.

Wystąpienie utknięcia w pętli zostało usunięte przez zamknięcie Git-GUI. (Uruchomiłem git merge -i w powłoce bash.)

Inne zdarzenia miały miejsce prawdopodobnie z powodu dużej liczby plików w moim repozytorium. Stało się to głównie z plikami .cod, które później wyłączam z kontroli wersji. (Mam powód, aby dokładnie je śledzić.) Uważam, że przyczyna może być związana z szybkością, z jaką Git używa uchwytów plików.

Zastanawiam się, czy problem, który można wyczyścić przez odpowiedź, jest związany z systemem Windows, ponieważ dwa poprzednie plakaty wspominały o systemie Windows, a nikt nie powiedział, że ma problem z innymi systemami operacyjnymi.

Miałem otwarty PHPStorm, zamknąłem go i wszystko było dobrze.

Miałem ten sam problem i zamknąłem wszystkie powiązane programy z Menedżera zadań systemu Windows. Jednak nadal nie działał. Interesujące jest to, że zamiast „Git pull” uruchomiłem „Git rebase” i zadziałało!

Żadna z powyższych odpowiedzi nie działa dla mnie, ale uruchamiam polecenie git gc z opcją force i rozwiązało mój przypadek.

„git gc --force”

[Windows 7, uruchom jako administrator => wiersz polecenia]

Spróbuj uruchomić edytor wiersza poleceń w trybie administracyjnym i uruchom polecenie. Pomaga i rozwiązuje problem. :)

W moim przypadku miałem starą metodę przycinania tagów powodujących problem. Rozwiązałem to rozbrajając oryginał:

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

następnie dodając to do przycinania usuniętych gałęzi na serwerze:

git config --global fetch.pruneTags true

Napotkałem ten sam błąd i rozwiązałem go, zamykając zaćmienie i ponownie pociągając, gdy plik był używany.