motiejus
/
jgit
1
Fork 0
Code Releases Activity

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>
This commit is contained in:
Jens Baumgart 2010-12-06 13:40:07 +01:00
parent 90fbc1db3a
commit cbf5ff6ac7
1 changed files with 20 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
org.eclipse.jgit/src/org/eclipse/jgit/storage/file/LockFile.java
View File

@ -397,7 +397,7 @@ public boolean commit() {
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 @@ private boolean deleteRef() {
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();