<div dir="auto">Thanks for this, I'll see if I can exclude this directory and I'll try it out tomorrow. <br><br><div data-smartmail="gmail_signature">Andrew Maclean</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 26 Sep. 2018, 21:29 Brad King, <<a href="mailto:brad.king@kitware.com">brad.king@kitware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/26/2018 12:22 AM, David Gobbi wrote:<br>
> Brad, have there been any new discoveries about why compiler tests<br>
> and custom-command outputs fail to open their output files on Windows<br>
> as described in [cmake issue 12957]?<br>
<br>
That failure was due to not being able to remove or replace the<br>
`.exe` files used for the checks, and it was almost always due to<br>
an antivirus tool locking the files.  That's why the fix was to<br>
just use a different `.exe` name each time.  Even without an AV<br>
tool, NTFS does not have synchronous delete operations.  We could<br>
work around that by renaming a file out of the way before deleting<br>
it, but so far the existing workaround has been sufficient (and the<br>
renaming could also race with AV locks).<br>
<br>
Using a different name isn't an option here, but also this one looks<br>
a bit different because it is about reading a file just after it is<br>
written.  Likely the antivirus tool is monitoring all filesystem<br>
operations and opens the file just after creation in order to scan<br>
it.  Since the purpose of the check is to avoid letting viruses run<br>
the AV tool likely opens the file without any sharing permissions.<br>
<br>
This kind of AV operation is mostly invisible for humans creating<br>
and reading files, but causes headaches for build systems and other<br>
use cases that do rapid creation and use of files.  I think the best<br>
solution is to just exclude one's development directories from the<br>
AV configuration.<br>
<br>
-Brad<br>
</blockquote></div>