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:
parent
90fbc1db3a
commit
cbf5ff6ac7
|
@ -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();
|
||||
|
|
Loading…
Reference in New Issue