.pack file from git repo can't be deleted using File delete() method

Question

For this method I am writing, I am cloning a git repo using the jgit library, then doing some stuff with those files, then finally I want to delete the repo. The problem I'm having is that when I call the delete() method on a .pack file (located in .git\objects\pack), it can't be deleted. All other files can be deleted though. Why does this happen?

Answer 1

Just found a clean way to do it: After doing stuff with your repo, close your git object this way :

Git git;
...
git.getRepository().close();
//then delete files

Answer 2

You can see that Java apps based on JGit have a tendency to disble ddd by default.
See this config file for Gitblit for instance:

# When true, JGit will use mmap() rather than malloc()+read() to load data from
# pack files. The use of mmap can be problematic on some JVMs as the garbage
# collector must deduce that a memory mapped segment is no longer in use before
# a call to munmap() can be made by the JVM native code.
#
# In server applications (such as Gitblit) that need to access many pack files,
# setting this to true risks artificially running out of virtual address space,
# as the garbage collector cannot reclaim unused mapped spaces fast enough.
#
# Default on JGit is false. Although potentially slower, it yields much more
# predictable behavior.
# Documentation courtesy of the Gerrit project.
#
# SINCE 1.0.0
# RESTART REQUIRED
git.packedGitMmap = false

---

This is consistent with the JGit thread you found:

I ran into another instance of not being able to delete a cloned repository in windows.
This one appears linked to the use of "PackedGitMMAP".
Is this a known problem with trying to use virtual memory mapping?

Yes.
The problem is the JVM does not release the memory mapping until the mapping is garbage collected by the Java GC.
This can happen at any time in the future, possibly never if there is insufficient memory pressure to force the GC to really look for garbage and reclaim.
This is why we disable the feature by default, we can't predict when the JVM will finally release the file.

In this test case if I "setPackedGitMMAP=false" then the repository is deleted successfully.

Yes. This is why this is the default.