34

When running git gc, I keep seeing this error:

rm: cannot unlink 'pack-30b1ff2[reset of hash].pack': Permission denied

What can/should I do about this error?

Update

Sorry, I should have provided more info. Yes, I have tried a reboot. In fact,reboots have fixed gc issues for me before.

I only noticed this issue because when I open Git Gui, it prompts me now and then to compress the database. I eventually noticed that after a couple of times opening Git Gui that it kept prompting me, even though I clicked Yes, and it came back "successful".

So then I tried running it with Git EXT's Settings - Git maintenance - Compress git database command. This command told me that there was an error (red light in Git EXT whereas there was a green light in Git Gui).

The error I posted above however was from running git gc straight from git bash.

Should I schedule a disk scan? Could bad sectors be causing this? I was hoping this would be a quick answer :(

danludwig
  • 46,965
  • 25
  • 159
  • 237
  • 1
    Check the permissions, and if they look sane, do backup and check your filesystem. – Mat May 05 '12 at 12:34
  • This is on windows 7. Should I check permissions on the .git folder? Does git run as my user account? I am an administrator, and that group has Full Control on the .git folder. – danludwig May 05 '12 at 12:40
  • Sorry, had assumed Linux. I never understand the exact details of windows permissions. But you shouldn't be dev'ing with an administrator account in the first place. – Mat May 05 '12 at 12:43
  • Have you tried a reboot? Some process may be using that file, preventing it's removal. – Pedro Rodrigues May 05 '12 at 16:11
  • I've updated my question, sorry, I should have provided more info from the start. – danludwig May 05 '12 at 17:55

4 Answers4

30

"Permission denied" on Windows is often caused by a lock from a running process. It's probable that there is a stalled Git EXT thread opened the pack file.

Try to do the git gc in safe mode.

Another option is to clone the repository in a new place and delete the old one.

Dmitry Ovsyanko
  • 1,416
  • 11
  • 6
  • Thanks, I was hoping to avoid having to reclone, so hopefully safe mode will work. Will try on next reboot. – danludwig May 05 '12 at 18:14
  • 1
    Didn't even need safe mode. I ran git gc first thing after a normal boot, and there was no permission denied error. Thanks. – danludwig May 06 '12 at 16:07
  • @danludwig first thing after a normal boot worked great for me too! Thanks for the hint! – cregox May 15 '13 at 12:13
  • 1
    In my case it was devenv.exe (some Git plugin inside Visual Studio) locking the files. [LockHunter](http://lockhunter.com) is a good tool for finding these, and you can script it from the command line to force unlock files: `"%PROGRAMFILES%\LockHunter\LockHunter.exe" /unlock "%CD%\.git\objects\pack" /silent && git gc` – Richard Dingwall May 30 '13 at 13:58
  • 4
    Ah, I forgot about the various plugins/extensions that might use git. In my case closing Eclipse before running `git gc` did the trick. – jacobq Sep 25 '13 at 15:08
  • 1
    In my case it was Eclipse (with the EGit plugin installed) that locked the files. While [Unlocker](http://www.emptyloop.com/unlocker/) was not able to detect Eclipse as the locking application, [LockHunter](http://lockhunter.com/) was. Thanks @RichardDingwall for the tip! – sschuberth Nov 27 '13 at 11:41
18

In my case it was TortoiseGit. To solve the problem I opened TortoiseGit Settings->Icon Overlays and set the Status cache to "None". Now the process TGitCache ended, so that all objects are "free" to be processed by git gc.

enter image description here

schoetbi
  • 12,009
  • 10
  • 54
  • 72
1

You need to close your console where the command that locked the command occurs. This could be VI that is locking the file or any command that was killed. The easiest solution is to close everything and reopen. You should be able to execute the command without problem.

Patrick Desjardins
  • 136,852
  • 88
  • 292
  • 341
1

Git 2.23 (Q3 2019) should avoid a permission denied issue during gc because of the commit graph (introduced in Git 2.18), which does precompute and store information necessary for ancestry traversal in a separate file to optimize graph walking.

With Git 2.23, the commit-graph file is part of the "files that the runtime may keep open file descriptors on, all of which would need to be closed when done with the object store", and the file descriptor to an existing commit-graph file now is closed before "gc" finalizes a new instance to replace it.

See commit 2d511cf, commit 5472c32, commit c3a3a96 (17 May 2019) by Derrick Stolee (derrickstolee).
(Merged by Junio C Hamano -- gitster -- in commit 5cb7c73, 09 Jul 2019)

packfile: close commit-graph in close_all_packs

The close_all_packs() method is used to close all read handles to pack-files and the multi-pack-index before running 'git gc --auto'.
This is particularly important on the Windows platform, where read handles block any writes to those files.
Replacing one of these files with a rename() will fail in this situation.

The commit-graph also performs a rename, so is susceptable to this problem.
We are careful to close the commit-graph before writing, but that doesn't work when a 'git fetch' (or similar) process runs 'git gc --auto' which may write a commit-graph.

Here, close the commit-graph as part of close_all_packs().

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250