[PATCH] Improve reliability of file renaming in Windows

[Yung, Douglas via llvm-commits]

I’m not familiar with that problem, so I can’t answer that question. Do you have a link to a bug or details about it?

The problem we saw it fix involved the compiler leaving temporary files when it tried to rename them. If llvm-ar utilizes the code update by my patch, it will likely fix the issue with llvm-ar.

Douglas Yung

From: Sean Silva [mailto:chisophugis at gmail.com]
Sent: Wednesday, March 16, 2016 12:08 AM
To: Yung, Douglas
Cc: llvm-commits at lists.llvm.org
Subject: Re: [PATCH] Improve reliability of file renaming in Windows

Does this fix the issue with llvm-ar leaving temporary files around when it calls rename?

-- Sean Silva

On Mon, Mar 14, 2016 at 10:18 PM, Yung, Douglas via llvm-commits <llvm-commits at lists.llvm.org<mailto:llvm-commits at lists.llvm.org>> wrote:
Ping.

From: Yung, Douglas
Sent: Friday, March 04, 2016 5:58 PM
To: 'llvm-commits at lists.llvm.org<mailto:llvm-commits at lists.llvm.org>'
Subject: RE: [PATCH] Improve reliability of file renaming in Windows

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<mailto: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

_______________________________________________
llvm-commits mailing list
llvm-commits at lists.llvm.org<mailto:llvm-commits at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160316/72f6fca2/attachment-0001.html>