[PATCH] Improve reliability of file renaming in Windows

[Yung, Douglas via llvm-commits]

Hi, I have put this change up for review at http://reviews.llvm.org/D17903.

Douglas Yung

From: Yung, Douglas
Sent: Thursday, March 03, 2016 8:34 PM
To: llvm-commits at lists.llvm.org
Subject: [PATCH] Improve reliability of file renaming in Windows

Hi,

In our internal testing, we found an issue where the compiler was failing to rename a temporary file due to a background process accessing the file. Upon investigation, we tracked the issue down to the rename() helper function in the LLVM Windows support libraries. This function was calling ReplaceFileW(), and if there was an error condition, it was bailing out of a retry loop if the error was not one of three errors: ERROR_ACCESS_DENIED, ERROR_FILE_NOT_FOUND or ERROR_SHARING_VIOLATION. The problem was that the function did not handle 3 additional possible error codes that are possible with ReplaceFileW() that also merit a retry. These error codes are ERROR_UNABLE_TO_MOVE_REPLACEMENT, ERROR_UNABLE_TO_MOVE_REPLACEMENT_2 and ERROR_UNABLE_TO_REMOVE_REPLACED and are documented on MSDN at https://msdn.microsoft.com/en-us/library/windows/desktop/aa365512(v=vs.85).aspx.

For each of these new error codes, the compiler should retry the replace/move operation. In the case of ERROR_UNABLE_TO_REMOVE_REPLACED, the compiler should retry the replace operation, however it should only retry using ReplaceFileW() and not MoveFileExW() as the former is preferred. In the case of ERROR_UNABLE_TO_MOVE_REPLACEMENT and ERROR_UNABLE_TO_MOVE_REPLACEMENT_2, the compiler should attempt to retry, however it should only use MoveFileEx() since the failed call to ReplaceFileW() would have deleted the target file without renaming the source file.

The attached patch makes the compiler aware of these three additional error codes so that it can handle them correctly and seems to have fixed the problem in our testing. This change unfortunately does not include a test as I did not know how to create a test that could trigger these error codes to be returned from ReplaceFileW(). We tested this change by using the compiler in a situation that was reported to often hit this issue and noted that the compilations all succeeded once this fix had been applied.

Douglas Yung
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160305/79501517/attachment.html>