aboutsummaryrefslogtreecommitdiff
path: root/entry.c
diff options
context:
space:
mode:
authorJohannes Sixt <j6t@kdbg.org>2009-04-03 08:49:59 +0200
committerJunio C Hamano <gitster@pobox.com>2009-04-20 03:42:53 -0700
commit6ac6f87818edfd33fea8ce3c95b47fe00a4e4b91 (patch)
tree3a2113c9d9dc551b83d07d069236fd1487f51386 /entry.c
parentccb4b5391382f4cdb5e5be49036e82e7d837b7af (diff)
downloadgit-6ac6f87818edfd33fea8ce3c95b47fe00a4e4b91.tar.gz
git-6ac6f87818edfd33fea8ce3c95b47fe00a4e4b91.tar.xz
Windows: Work around intermittent failures in mingw_rename
We have replaced rename() with a version that can rename a file to a destination that already exists. Nevertheless, many users, the author included, observe failures in the code that are not reproducible. The theory is that the failures are due to some other process that happens to have opened the destination file briefly at the wrong moment. (And there is no way on Windows to delete or replace a file that is currently open.) The most likely candidate for such a process is a virus scanner. The failure is more often observed while there is heavy git activity (for example while the test suite is running or during a rebase operation). We work around the failure by retrying the rename operation if it failed due to ERROR_ACCESS_DENIED. The retries are delayed a bit: The first only by giving up the time slice, the next after the minimal scheduling granularity, and if more retries are needed, then we wait some non-trivial amount of time with exponential back-off. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'entry.c')
0 files changed, 0 insertions, 0 deletions