MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0009640CMakeCPackpublic2009-10-02 05:302016-06-10 14:31
ReporterClaudio Bley 
Assigned ToBill Hoffman 
PrioritynormalSeveritymajorReproducibilityrandom
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0009640: ERROR_SHARING_VIOLATION in CopyFileTime function
DescriptionTrying 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.
Steps To Reproduce
Additional InformationInvestigating, I found out that it was caused by my anti-virus software blocking access to the file until it has decided whether the file is malicious or not.

That lead to a race-condition and at some point in
the packaging process CPack always failed updateing the timestamps, because the AV software had not completed examining the file.

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...
TagsNo tags attached.
Relationships
Attached Filesdiff cmake_sharing_violation.diff (1,256) 2009-10-02 05:30
https://public.kitware.com/Bug/file/2512/cmake_sharing_violation.diff
Issue History
Date ModifiedUsernameFieldChange
2009-10-02 05:30Claudio BleyNew Issue
2009-10-02 05:30Claudio BleyFile Added: cmake_sharing_violation.diff
2009-10-02 11:59Bill HoffmanStatusnew => assigned
2009-10-02 11:59Bill HoffmanAssigned To => David Cole
2009-10-02 12:13Bill HoffmanNote Added: 0017904
2009-12-11 17:51David ColeNote Added: 0018832
2009-12-11 17:52David ColeNote Added: 0018833
2009-12-11 17:52David ColeAssigned ToDavid Cole => Bill Hoffman
2010-05-07 08:29Claudio BleyNote Added: 0020640
2010-07-28 09:35Claudio BleyNote Edited: 0020640
2016-06-10 14:27Kitware RobotNote Added: 0041600
2016-06-10 14:27Kitware RobotStatusassigned => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0017904)
Bill Hoffman   
2009-10-02 12:13   
It would be helpful if you could provide a smaller example of this, but I understand the issue now.
(0018832)
David Cole   
2009-12-11 17:51   
I don't think we should fix this in CMake/CPack. I don't think it's a good idea to "loop until successful" with an "open file for writing" API...

The easy workaround for this issue is to exclude your building/installing/packaging directories from your virus checker. Check the final product after its built, not while you're assembling the package.
(0018833)
David Cole   
2009-12-11 17:52   
Assigning to Bill.

Bill, I recommend we resolve this as "won't fix"...
(0020640)
Claudio Bley   
2010-05-07 08:29   
(edited on: 2010-07-28 09:35)
> I don't think we should fix this in CMake/CPack. I don't think it's a good idea
> to "loop until successful" with an "open file for writing" API...

There is a limit, so it times out quickly when unsuccessful. Furthermore, it only does this for a specific error code (SHARING_VIOLATION) which might be caused by any program on your computer.

> The easy workaround for this issue is to exclude your building/installing
> /packaging directories from your virus checker. Check the final product after
> its built, not while you're assembling the package.

What if I'm not in control of whether or not the virus software is active on my development machine?

edit 2010-07-28:

Btw, it is quite a PITA always having to recompile CPack when a new Release comes out since the provided binary just doesn't work.
(0041600)
Kitware Robot   
2016-06-10 14:27   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.