Git - Unlink of file .idx and .pack failed (The only process owned handle to this file is git.exe) [duplicate]

Question

Please, look at this picture! could be git that stupid? Git couldn't unlink some file, but only git.exe is holding a handle to this file. (Permissions are ok - Full control) Please, is there a safe solution for this problem? My Git version is 1.9.5-preview20141217

Shishko

Perhaps someone messed up the permissions on the file (or a subdirectory leading to the file) so that the user currently running git doesn't have permission to delete it... – Para

Hi, I checked all permissions and there is "full control" for Admin, and I'm admin on this machine. – Shishko

Hi, was there ever a solution to this? I have the same problem. – Peppergrass

Hi, now I have a new PC and do not have this problem. So maybe the solution is checkout the git repository to new folder or maybe newer version of git fixed it. – Shishko

That should no longer occur with Git 2.19 (Q3 2018). See my answer below. – Shulem

Answer 1

Git 2.19 (Q3 2018) improves the file descriptors management for the packfiles, and avoid the "Unlink of file... failed. Should I try again?" error message.

See commit 12e73a3 (09 Jul 2018) by Kim Gybels (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit 562413e, 02 Aug 2018)}

gc --auto: release pack files before auto packing

"git gc --auto" opens file descriptors for the packfiles before spawning "git repack/prune", which would upset Windows that does not want a process to work on a file that is open by another process.

Teach gc --auto to release pack files before auto packing the repository to prevent failures when removing them.

Also teach the test 'fetching with auto-gc does not lock up' to complain when it is no longer triggering an auto packing of the repository.

This solves the Git for Windows issue "Unlink of file XXX failed. Should I try again?", with PR 1769.

---

Another improvement: With Git 2.34 (Q4 2021), the run-command API has been updated so that the callers can easily ask the file descriptors open for packfiles to be closed immediately before spawning commands that may trigger auto-gc.

See commit c4dee2c, commit 5a22a33, commit 28d04e1, commit 3322a9d (09 Sep 2021), and commit 7e44ff7, commit 957ba81 (08 Sep 2021) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit c042ad5, 20 Sep 2021)}

c4dee2c085:Close object store closer to spawning child processes

^{Signed-off-by: Johannes Schindelin}

In many cases where we spawned child processes that may trigger a repack, we explicitly closed the object store first (so that the repack process can delete the .pack files, which would otherwise not be possible on Windows since files cannot be deleted as long as they as still in use).

Wherever possible, we now use the new close_object_store bit of the run_command() API, to delay closing the object store even further.
This makes the code easier to maintain because it is now more obvious that we only release those file handles because of those child processes.

Shulem

Answer 2

I had this issue and solved it by the command : git gc The above command remove temp and unnecessary files (Garbage Collector): https://mcmap.net/q/53616/-unlink-of-file-failed-should-i-try-again

Oeo