JGit locks itself on Windows after update to 7.2.0

[veita]

Version

7.2.0

Operating System

Windows

Bug description

After updating JGit from 6.10.0.202406032230-r to 7.2.0.202503040940-r, tests on Windows consistently fail because some JGit operations appear to interfere with subsequent ones.

It seems that JGit keeps files locked after calls have been returned:

java.io.UncheckedIOException: java.nio.file.FileSystemException: C:\path\to\repository\.git\objects\pack\pack-80b5e7ae5d2e589e2625fb903fb73c0484147893.pack:
  The process cannot access the file because it is being used by another process
	at com.acme.test.io.TestIOHelper.delete(TestIOHelper.java:1119)
	at com.acme.test.AbstractTestWorkingDir.close(AbstractTestWorkingDir.java:156)
	at com.acme.test.TestCaseBase.tearDown(TestCaseBase.java:373)
	at com.acme.test.TestCaseBase.runBare(TestCaseBase.java:1717)
	at junit.framework.TestResult$1.protect(TestResult.java:122)
	at junit.framework.TestResult.runProtected(TestResult.java:142)
	at junit.framework.TestResult.run(TestResult.java:125)
	at junit.framework.TestCase.run(TestCase.java:130)
	at junit.framework.TestSuite.runTest(TestSuite.java:241)
	at junit.framework.TestSuite.run(TestSuite.java:236)
Caused by: java.nio.file.FileSystemException: C:\path\to\repository\.git\objects\pack\pack-80b5e7ae5d2e589e2625fb903fb73c0484147893.pack:
  The process cannot access the file because it is being used by another process
	at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)
	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
	at java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:273)
	at java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:104)
	at java.base/java.nio.file.Files.delete(Files.java:1152)
...
	... 9 more

File Leak Detector reported open file descriptors from Pack.doOpen.

#1 /path/to/repository/.git/objects/pack/pack-8ab2a0e5297aa51b3229fbdf52822cacc0cffe6c.pack by thread:main on Mon Mar 24 18:57:10 CET 2025
	at java.base/java.io.RandomAccessFile.<init>(RandomAccessFile.java:224)
	at org.eclipse.jgit.internal.storage.file.Pack.doOpen(Pack.java:702)
	at org.eclipse.jgit.internal.storage.file.Pack.beginWindowCache(Pack.java:677)
	at org.eclipse.jgit.internal.storage.file.WindowCache.load(WindowCache.java:563)
	at org.eclipse.jgit.internal.storage.file.WindowCache.getOrLoad(WindowCache.java:655)
	at org.eclipse.jgit.internal.storage.file.WindowCache.get(WindowCache.java:389)
	at org.eclipse.jgit.internal.storage.file.WindowCursor.pin(WindowCursor.java:321)
	at org.eclipse.jgit.internal.storage.file.WindowCursor.copy(WindowCursor.java:221)
	at org.eclipse.jgit.internal.storage.file.Pack.readFully(Pack.java:647)
	at org.eclipse.jgit.internal.storage.file.Pack.load(Pack.java:848)
	at org.eclipse.jgit.internal.storage.file.Pack.get(Pack.java:287)
	at org.eclipse.jgit.internal.storage.file.PackDirectory.open(PackDirectory.java:223)
	at org.eclipse.jgit.internal.storage.file.ObjectDirectory.openPackedObject(ObjectDirectory.java:412)
	at org.eclipse.jgit.internal.storage.file.ObjectDirectory.openPackedFromSelfOrAlternate(ObjectDirectory.java:375)
	at org.eclipse.jgit.internal.storage.file.ObjectDirectory.openObjectWithoutRestoring(ObjectDirectory.java:365)
	at org.eclipse.jgit.internal.storage.file.ObjectDirectory.openObject(ObjectDirectory.java:350)
	at org.eclipse.jgit.internal.storage.file.WindowCursor.open(WindowCursor.java:133)
	at org.eclipse.jgit.lib.ObjectReader.open(ObjectReader.java:216)
	at org.eclipse.jgit.revwalk.RevWalk.parseAny(RevWalk.java:1167)
	at org.eclipse.jgit.revwalk.RevWalk.parseCommit(RevWalk.java:1078)
...

We do not know whether this error does any harm to Git repositories on Windows or Linux.

Actual behavior

JGit throws Exceptions due to file locks.

Expected behavior

Multiple JGit operations executed in the same thread should not lead to exceptions.

[msohn]

Windows doesn't allow to delete files which have open file handles.

RepositoryCache doesn't close open pack files immediately after the respective Repository instance has been closed to avoid trashing on the WindowCache which is caching pages of pack files on the heap, see change 74904.

Ensure you close all Repository instances. In addition you can set core.repositoryCacheExpireAfter = 0 and/or call RepositoryCache.clear() to ensure pack files are closed immediately.

[MarkEWaite]

I'm seeing open file handles in the Jenkins git client plugin while evaluating JGit 7.2.0. I've checked as thoroughly as I can to confirm that I'm closing all Repository instances and I'm still seeing open file handles with JGit 7.2.0 that I do not see with JGit 7.0.0.

The detailed steps that I use to see the problem through Jenkins are described in https://github.com/MarkEWaite/JGit-7.2.0 .

I'll continue checking to see if I can find the root cause of the leak in my code, but wanted to post here to note that I'm also interested.

[JoostK]

Possibly related to #66 and https://review.gerrithub.io/c/eclipse-jgit/jgit/+/1204695, although the latter should only affect concurrent deletions of multiple repositories I believe.

I am personally not seeing any file locking issues in unit tests on Windows with JGit 7.2.