Hủy liên kết tệp không thành công


169

Tôi đang cố gắng thực hiện thao tác kéo git và tôi gặp lỗi sau:

Hủy liên kết tệp 'lib / xxx.jar' không thành công. Tôi có nên thử lại không? (y / n)

Không có vấn đề gì nếu tôi chọn y hoặc n, không thể đến trạng thái mà tôi có thể kéo hoặc đẩy.


Bạn đã kiểm tra nếu bạn có quyền ghi vào tập tin đó?
Raphael Michel

1
chạy bên phải chmodvà / hoặc chowntrên tập tin nói.
Not_a_Golfer

Tôi nên có quyền, nếu không tôi sẽ chown / chmod nó!
marko


Câu trả lời:


204

Điều đó thường có nghĩa là một quy trình vẫn đang sử dụng tệp cụ thể đó (vẫn có phần xử lý trên đó)
(trên Windows, ProcessExplorerrất tốt để theo dõi loại quy trình đó)

Hãy thử đóng các chương trình khác của bạn và thử lại git pull.

Lưu ý rằng bạn có một thay thế với GIT_ASK_YESNObiến .


Cập nhật tháng 1 năm 2019:

Điều đó thậm chí còn được sửa chữa nhiều hơn, với Git 2.21 (Q1 2019), vì " git gc" và " git repack" không đóng các gói đóng mở mà họ thấy không cần thiết trước khi xóa chúng, không hoạt động trên nền tảng không có khả năng xóa tệp đang mở.
Điều này đã được sửa chữa.

Xem cam kết 5bdece0 (15 tháng 12 năm 2018) của tác giả Julian Schindelin ( dscho) .
(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết 5104f8f , ngày 18 tháng 1 năm 2019)

gc/ repack: phát hành gói khi cần

Trên Windows, các tệp không thể bị xóa hoặc đổi tên nếu vẫn có các thẻ được xử lý theo quy trình.
Để khắc phục điều đó, chúng tôi đã giới thiệu close_all_packs()chức năng.

Trước đó, chúng tôi đã đảm bảo rằng các gói được phát hành ngay trước khi git gcđược sinh ra, trong trường hợp gcmuốn loại bỏ các gói không còn cần thiết.

Nhưng nhà phát triển này quên rằng gcbản thân họ cũng cần phải bỏ các gói, ví dụ như khi hợp nhất tất cả các gói thông qua --aggressivetùy chọn.

Tương tự như vậy, git repack -dmuốn xóa các gói lỗi thời và do đó cũng cần phải đóng tất cả các tay cầm gói.


Cập nhật tháng 1 năm 2016

Điều đó nên được sửa trong Git 2.8 (tháng 3 năm 2016) (và xem Git 2.19, quý 3 năm 2018 bên dưới)

Xem cam kết d562102 , cam kết dcacb1b , cam kết df617b5 , cam kết 0898c96 (ngày 13 tháng 1 năm 2016) của tác giả Julian Schindelin ( dscho) .
(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết 3c80940 , ngày 26 tháng 1 năm 2016)

fetch: phát hành tệp gói trước khi thu gom rác

Trước khi tự động gc'ing, chúng tôi cần đảm bảo rằng các tệp gói được phát hành trong trường hợp chúng cần được đóng gói lại và thu gom rác.

Nhiều loại tiền mã hóa chạy " gc --auto" trước khi thoát các packfiles được ánh xạ và để các mô tả tệp cho chúng mở, không thân thiện với các hệ thống không thể xóa các tệp đang mở.
Bây giờ họ đóng các gói trước khi làm như vậy.

Khắc phục sự cố git-for-widows500 .

Nhìn vào thử nghiệm được sử dụng để xác nhận cách tiếp cận mới đó , một cách giải quyết khả thi (vì Git 2.8 chưa được đưa ra) sẽ được nâng lên một cách giả tạo gc.autoPackLimit.

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

git 2.8.4 (tháng 6 năm 2016) không đề cập đến vấn đề 755 , điều này cũng sẽ làm giảm bớt vấn đề ( cam kết 2db0641 ):

Đảm bảo rằng các tệp xử lý tạm thời không được kế thừa bởi các tiến trình con


Trên thực tế, git-for-windowsvấn đề 500 được đề cập ở trên thực sự đã được khắc phục với Git 2.19, Q3 2018.
Xem " Git - Hủy liên kết tệp .idx.packkhông thành công (Quá trình duy nhất sở hữu xử lý tệp này là git.exe) "


5
Nhiều khả năng có một JVM đang chạy bằng tệp jar đó.
Thorbjørn Ravn Andersen

2
Trong trường hợp của tôi đó là Skype. Tôi trước đó đã chuyển tập tin cho người khác và một số chưa được chấp nhận hoặc hủy bỏ.
Vivek Kodira

6
Tôi thấy Windows Explorer là thủ phạm. Rất có thể là do lớp phủ biểu tượng của TortoiseGit hoặc TGitCache. Đóng tất cả các thư mục đang mở đã thực hiện thủ thuật, nhưng bạn có thể chỉ cần đóng thư mục dự án nếu mở.
Allan Bogh

4
Trong trường hợp của tôi, đó là VS2013 vì nó bị ràng buộc với giải pháp mở.
BrotherOdin

2
Explorer.exe là vấn đề của tôi - Tôi không có TortoiseGit. Tôi đã giết explorer.exe từ Trình quản lý tác vụ và sinh ra một cái mới bằng cách sử dụng CTRL-ALT-DELETE => Trình quản lý tác vụ => Tệp => Chạy tác vụ mới => "explorer.exe" (không có dấu ngoặc kép)
joehanna

57

Đây là một câu trả lời cụ thể của Windows, vì vậy tôi biết rằng nó không liên quan đến bạn ... Tôi chỉ bao gồm nó vì lợi ích của những người tìm kiếm trong tương lai.

Trong trường hợp của tôi, đó là vì tôi đang chạy Git từ một dòng lệnh không nâng cao. "Chạy với tư cách quản trị viên" đã sửa nó cho tôi.


4
Tôi gặp vấn đề này trên Windows 7 khi thực hiện thao tác kéo và git đã thực hiện gói tự động. Nó phàn nàn về các tập tin "idx". Sau đó tôi đã mở một cửa sổ giao diện điều khiển với tư cách quản trị viên và chạy git gc và không có vấn đề gì. Vì vậy, đây là một giải pháp tốt.
grahamesd

1
git gc đã làm điều đó cho tôi trên Windows 7. Nó đã xảy ra b / c Tôi đang thực hiện thao tác git trên cmder trong khi thực hiện một cú hích trên WebStorm
Alessandro

2
Ồ Cảm ơn NeilD. Nó sửa nó cho tôi quá. Sẽ thật tuyệt khi chuyển GIT sang Windows thêm một chút.
Martin Dobšík 30/03/2016

Chà ... nó cần 6 năm trước. Hiện nay? Ai biết? _ (ツ) _ /
NeilD

30

Đối với tôi, đó là vì Visual Studio đã cố tải lại tất cả các tệp đã thay đổi từ pull. Có làm mới studio hình ảnh, sau đó chạy git gc.


3
Tương tự đối với tôi. Eclipse cần phải được đóng trước khi chạy git gc.
alfoks

5

Trên Windows sử dụng GitHub cho Windows, tôi gặp lỗi tương tự trong trình bao khi chạy git gc:

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

Tôi đã giải quyết nó bằng cách đóng GUI GitHub.


2

Cố gắng khởi động lại Apache hoặc máy chủ web khác vì nó có thể đã khóa một số tệp của bạn.


2

Đã đóng Visual Studio và Rubymine và không gặp lỗi nữa. Một trong số đó là thủ phạm.



1

Tôi cũng gặp vấn đề này, nhưng tôi phát hiện ra đó là UltraEdit, vì tôi đã sử dụng UE để tổ chức và chỉnh sửa không gian làm việc nhật thực của mình ~ ~

Có thể do UE xử lý phiên bản cũ của tệp cụ thể, Git không thể hủy liên kết tệp đó.

Sau khi tôi đóng UltraEdit, vấn đề không bao giờ xảy ra nữa.


1

Điều này được gây ra trong trường hợp của tôi bởi SimpLESS, trình biên dịch LESS. Bạn phải đóng nó trong systray.


0

Vấn đề là bởi vì bạn đang có một số chương trình xử lý các tệp này. Tôi có một gợi ý rằng bạn nên sử dụng Unlocker để tìm chương trình xử lý nó:

Mở khóa


0

Tôi đã có điều này xảy ra trên Windows XP, cả hai đều có thông báo bị kẹt trong một vòng lặp và có thể bị xóa bằng cách trả lời.

Xảy ra tình trạng kẹt trong vòng lặp đã được xóa bằng cách đóng Git-GUI. (Tôi đang chạy git merge -i trong bash shell.)

Các sự cố khác xảy ra có thể là do số lượng lớn tệp trong kho lưu trữ của tôi. Nó xảy ra chủ yếu với các tệp .cod mà sau này tôi loại trừ khỏi kiểm soát phiên bản. (Tôi có một lý do để theo dõi chúng một cách thân mật.) Tôi tin rằng nguyên nhân có thể liên quan đến tốc độ mà Git sử dụng xử lý tệp.

Tôi tự hỏi liệu vấn đề có thể được giải quyết bằng cách trả lời có liên quan đến Windows hay không, vì hai áp phích trước đã đề cập đến Windows, và không ai nói rằng họ có vấn đề với các hệ điều hành khác.


0

Tôi đã mở PHPStorm, đóng nó và tất cả đều ổn.


0

Tôi gặp vấn đề tương tự và tôi đã đóng tất cả các chương trình liên quan từ Window Task Manager. Tuy nhiên, nó vẫn không hoạt động. Phần thú vị là tôi đã chạy "Git rebase" thay vì "Git pull" và nó đã hoạt động!


0

Không có câu trả lời nào ở trên không phù hợp với tôi, nhưng tôi chạy lệnh git gc với tùy chọn bắt buộc và nó đã giải quyết trường hợp của tôi.

'git gc - lực lượng'

[Windows 7, Chạy với tư cách quản trị viên => Dấu nhắc lệnh]


0

Hãy thử chạy trình soạn thảo dòng lệnh trong chế độ quản trị và chạy lệnh. Nó giúp và giải quyết vấn đề. :)


0

Trong trường hợp của tôi, tôi đã có một phương pháp cắt tỉa thẻ cũ gây ra vấn đề. Tôi đã giải quyết nó bằng cách bỏ cài đặt gốc:

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

sau đó thêm phần này để tỉa các nhánh đã xóa trên máy chủ:

git config --global fetch.pruneTags true

0

Tôi đã đối mặt với lỗi tương tự và giải quyết nó bằng cách đóng nhật thực và kéo lại khi tệp đang được sử dụng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.