[CMake] [PATCH] CPack fails because of a sharing violation

[Claudio Bley]

Bill Hoffman <bill.hoffman at kitware.com>
writes:

> Claudio Bley wrote:
>> Hi.
>>
>> Trying to build & install Boost I ran into the following error when
>> CPack was called:
>>
>> ,----
>> | CPack: -   Install component: fusion_headers
>> | CMake Error at libs/fusion/cmake_install.cmake:31 (FILE):
>> |   file Problem setting modification time on file
>> |   "C:/build/vc90nmake/boost_1_40_0/_CPack_Packages/win32/NSIS/Boost-1.40.0-vc9/fusion_headers/include/boost-1_40/boost/fusion/include/iterator_facade.hpp"
>> | Call Stack (most recent call first):
>> |   libs/cmake_install.cmake:48 (INCLUDE)
>> |   cmake_install.cmake:37 (INCLUDE)
>> | | CPack Error: Error when generating package: Boost
>> | NMAKE : fatal error U1077: ""C:\Programme\CMake 2.6\bin\cpack.exe"": Return-Code "0x1"
>> | Stop.
>> `----
>>
>> I debugged cpack.exe and realized that the error occured in
>> Source/cmSystemTools.cxx:CopyFileTime() when trying to open the target
>> file.
>>
>> GetLastError() returned ERROR_SHARING_VIOLATION. 
>>
>> According to
>> http://support.microsoft.com/?scid=kb%3Ben-us%3B316609&x=17&y=20 one
>> should retry attempting to open the file until successfull.
>>
>> I implemented this approach (see the following patch) and succeeded in
>> building an installer package for Boost.
>>
>> Of course, there a some other places where CreateFile is called and this
>> problem might happen there also. It might be a good idea to generalize
>> this into an utility function.
>>
>> Btw, do you realize that the cmSystemToolsWindowsHandle class is broken
>> according to its copy/assignment semantics?
>>
>>
>> Index: Source/cmSystemTools.cxx
>> ===================================================================
>> RCS file: /cvsroot/CMake/CMake/Source/cmSystemTools.cxx,v
>> retrieving revision 1.401
>> diff -u -r1.401 cmSystemTools.cxx
>> --- Source/cmSystemTools.cxx	11 Sep 2009 12:18:13 -0000	1.401
>> +++ Source/cmSystemTools.cxx	18 Sep 2009 14:43:23 -0000
>> @@ -2134,11 +2134,26 @@
>>  bool cmSystemTools::CopyFileTime(const char* fromFile, const char* toFile)
>>  {
>>  #if defined(_WIN32) && !defined(__CYGWIN__)
>> +  const DWORD retryDelay_millisecs = 250;
>> +  const int maxRetries = 15;
>> +  int retries = 0;
>> +
>>    cmSystemToolsWindowsHandle hFrom =
>>      CreateFile(fromFile, GENERIC_READ, FILE_SHARE_READ, 0,
>>                 OPEN_EXISTING, 0, 0);
>> -  cmSystemToolsWindowsHandle hTo =
>> -    CreateFile(toFile, GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0);
>> +
>> +  HANDLE hTry;
>> +
>> +  while ((hTry = CreateFile(toFile, GENERIC_WRITE, +
>> FILE_SHARE_WRITE, 0, OPEN_EXISTING, 0, 0)) == INVALID_HANDLE_VALUE
>> +         && GetLastError() == ERROR_SHARING_VIOLATION
>> +         && ++retries <= maxRetries) +    {
>> +    Sleep(retryDelay_millisecs);
>> +    }
>> +
>> +  cmSystemToolsWindowsHandle hTo(hTry);
>> +
>>    if(!hFrom || !hTo)
>>      {
>>      return false;
>>
>>
>
> Why is it trying to copy a file that is being used?
>
> Seems like there is some other issue here, and this just gets around a
> different bug...

At first, it is trying to copy the file time from one file to another,
and the _target_ file is locked by another process.

On a multi-processing operating system you can't control what other
processes are doing, and of course, some other process (or the user
herself) might actually open the file during the
file-time-copy-process.

In my case it is the anti-virus software blocking access to the file
until it has determined whether the file is malicious or not. That
leads to a race-condition and the file is usually unlocked before
CPack tries to open it to change the timestamps, but at some point in
the packaging process it always failed because the AV software had not
completed examining the file.

I would think that this is a perfectly valid usage scenario one would
have to cope with in the code.

Cheers,
Claudio