summaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.http.test/src/org/eclipse
diff options
context:
space:
mode:
authorChristian Halstrick <christian.halstrick@sap.com>2017-08-07 14:26:46 +0200
committerMatthias Sohn <matthias.sohn@sap.com>2017-08-14 21:09:48 +0200
commit1ed1e40387c859786cf1932d22fe0001fbd5abb6 (patch)
treec3fa7738c15745532cf650f2c29314243e9c0567 /org.eclipse.jgit.http.test/src/org/eclipse
parent3db0f507eee3e552f1bcf7343efb03adf34c9afa (diff)
downloadjgit-1ed1e40387c859786cf1932d22fe0001fbd5abb6.tar.gz
jgit-1ed1e40387c859786cf1932d22fe0001fbd5abb6.zip
Fix exception handling for opening bitmap index files
When creating a new PackFile instance it is specified whether this pack has an associated bitmap index file or not. This information is cached and the public method getBitmapIndex() will always assume a bitmap index file must exist if the cached data tells so. But it may happen that the packfiles are repacked during a gc in a different process causing the packfile, bitmap-index and index file to be deleted. Since JGit still has an open FileHandle on the packfile this file is not really deleted and can still be accessed. But index and bitmap index file are deleted. Fix getBitmapIndex() to invalidate the cached packfile instance if such a situation occurs. This problem showed up when a gerrit server was serving repositories which where garbage collected with native git regularly. Fetch and clone commands for certain repositories failed permanently after a native git gc had deleted old bitmap index files. Change-Id: I8e620bec74dd3f310ba42024f9a657062f868f0e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Diffstat (limited to 'org.eclipse.jgit.http.test/src/org/eclipse')
0 files changed, 0 insertions, 0 deletions