[vtk-developers] Python Wrapping fails in master build.

[Andras Lasso]

> it is about reading a file just after it is written

Reading a file right after it is written is probably one of the most common operations during a build process and it is done successfully by many tools on hundreds of thousands of files. It is odd that only vtkWrapPython runs into problems.

Is it possible that the .cxx file that cannot be created (https://public.kitware.com/pipermail/vtk-developers/2018-September/036360.html) existed before and has just been recently deleted? That would explain the problem you are having.

“The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED.” (https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-deletefilea)

If anti-virus software has any influence on the build process then most likely then there is some fragile mechanisms in place and the problem likely would occur with any other software that monitors the file system. You cannot possibly identify and disable all these software.

Andras

From: Andrew Maclean <andrew.amaclean at gmail.com>
Sent: Wednesday, September 26, 2018 7:34 AM
To: Brad King <brad.king at kitware.com>
Cc: David Gobbi <david.gobbi at gmail.com>; Andras Lasso <lasso at queensu.ca>; VTK Developers <vtk-developers at vtk.org>
Subject: Re: [vtk-developers] Python Wrapping fails in master build.

Thanks for this, I'll see if I can exclude this directory and I'll try it out tomorrow.
Andrew Maclean

On Wed, 26 Sep. 2018, 21:29 Brad King, <brad.king at kitware.com<mailto:brad.king at kitware.com>> wrote:
On 09/26/2018 12:22 AM, David Gobbi wrote:
> Brad, have there been any new discoveries about why compiler tests
> and custom-command outputs fail to open their output files on Windows
> as described in [cmake issue 12957]?

That failure was due to not being able to remove or replace the
`.exe` files used for the checks, and it was almost always due to
an antivirus tool locking the files.  That's why the fix was to
just use a different `.exe` name each time.  Even without an AV
tool, NTFS does not have synchronous delete operations.  We could
work around that by renaming a file out of the way before deleting
it, but so far the existing workaround has been sufficient (and the
renaming could also race with AV locks).

Using a different name isn't an option here, but also this one looks
a bit different because it is about reading a file just after it is
written.  Likely the antivirus tool is monitoring all filesystem
operations and opens the file just after creation in order to scan
it.  Since the purpose of the check is to avoid letting viruses run
the AV tool likely opens the file without any sharing permissions.

This kind of AV operation is mostly invisible for humans creating
and reading files, but causes headaches for build systems and other
use cases that do rapid creation and use of files.  I think the best
solution is to just exclude one's development directories from the
AV configuration.

-Brad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtk-developers/attachments/20180926/6d63d2ee/attachment-0001.html>