[PATCH] Improve reliability of file renaming in Windows

[Sean Silva via llvm-commits]

On Wed, Mar 16, 2016 at 2:24 PM, Yung, Douglas <
douglas_yung at playstation.sony.com> wrote:

> 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?
>

In my testing simply running llvm-ar creates a weird temporary file (it is
created internally to ReplaceFileW). I haven't gotten around to filing a PR
for it.

-- Sean Silva


>
>
> 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> wrote:
>
> Ping.
>
>
>
> *From:* Yung, Douglas
> *Sent:* Friday, March 04, 2016 5:58 PM
> *To:* '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
> *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
> 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/7ed7642a/attachment.html>