LockFile.commit: retry renaming

Currently the following can happen in LockFile.commit: deletion of the
original file succeeds but renaming fails afterwards. In this case the
original file (e.g. branch file in refs/heads) is lost.
To workaround the issue the same retry logic as for file deletion is
applied to file renaming.

Bug: 331890
Change-Id: I68620c07f2d3ab7f3279c71a91e184e8eac69832
Signed-off-by: Jens Baumgart <jens.baumgart@sap.com>
Signed-off-by: Philipp Thun <philipp.thun@sap.com>

1 files changed, 20 insertions, 1 deletions

diff --git a/org.eclipse.jgit/src/org/eclipse/jgit/storage/file/LockFile.java b/org.eclipse.jgit/src/org/eclipse/jgit/storage/file/LockFile.java
index 6199f4c450..c1fb704a51 100644
--- a/org.eclipse.jgit/src/org/eclipse/jgit/storage/file/LockFile.java
+++ b/org.eclipse.jgit/src/org/eclipse/jgit/storage/file/LockFile.java
@@ -397,7 +397,7 @@ public class LockFile {
 		if (lck.renameTo(ref))
 			return true;
 		if (!ref.exists() || deleteRef())
-			if (lck.renameTo(ref))
+			if (renameLock())
 				return true;
 		unlock();
 		return false;
@@ -422,6 +422,25 @@ public class LockFile {
 		return false;
 	}
 
+	private boolean renameLock() {
+		if (!fs.retryFailedLockFileCommit())
+			return lck.renameTo(ref);
+
+		// File renaming fails on windows if another thread is
+		// concurrently reading the same file. So try a few times.
+		//
+		for (int attempts = 0; attempts < 10; attempts++) {
+			if (lck.renameTo(ref))
+				return true;
+			try {
+				Thread.sleep(100);
+			} catch (InterruptedException e) {
+				return false;
+			}
+		}
+		return false;
+	}
+
 	private void saveStatInformation() {
 		if (needStatInformation)
 			commitLastModified = lck.lastModified();