View Issue Details [ Jump to Notes ]

[ Print ]

Project

Category

View Status

Date Submitted

Last Update

0009640

CMake

CPack

public

2009-10-02 05:30

2016-06-10 14:31

Reporter

Claudio Bley

Assigned To

Bill Hoffman

Priority

normal

Severity

major

Reproducibility

random

Status

closed

Resolution

moved

Platform

OS Version

Product Version

Target Version

Fixed in Version

Summary

0009640: ERROR_SHARING_VIOLATION in CopyFileTime function

Description

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.

Additional Information

Investigating, 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...

Tags

No tags attached.

Attached Files

cmake_sharing_violation.diff [^] (1,256 bytes) 2009-10-02 05:30 [Show Content] [Hide Content]

Index: Source/cmSystemTools.cxx
===================================================================
RCS file: /cvsroot/CMake/CMake/Source/cmSystemTools.cxx,v
retrieving revision 1.403
diff -u -r1.403 cmSystemTools.cxx
--- Source/cmSystemTools.cxx	1 Oct 2009 20:47:08 -0000	1.403
+++ Source/cmSystemTools.cxx	2 Oct 2009 07:13:27 -0000
@@ -2130,11 +2130,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;

Relationships

Notes
(0017904) Bill Hoffman (manager) 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 (manager) 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 (manager) 2009-12-11 17:52	Assigning to Bill. Bill, I recommend we resolve this as "won't fix"...

(0020640) Claudio Bley (reporter) 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 (administrator) 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.

Issue History
Date Modified	Username	Field	Change
2009-10-02 05:30	Claudio Bley	New Issue
2009-10-02 05:30	Claudio Bley	File Added: cmake_sharing_violation.diff
2009-10-02 11:59	Bill Hoffman	Status	new => assigned
2009-10-02 11:59	Bill Hoffman	Assigned To	=> David Cole
2009-10-02 12:13	Bill Hoffman	Note Added: 0017904
2009-12-11 17:51	David Cole	Note Added: 0018832
2009-12-11 17:52	David Cole	Note Added: 0018833
2009-12-11 17:52	David Cole	Assigned To	David Cole => Bill Hoffman
2010-05-07 08:29	Claudio Bley	Note Added: 0020640
2010-07-28 09:35	Claudio Bley	Note Edited: 0020640
2016-06-10 14:27	Kitware Robot	Note Added: 0041600
2016-06-10 14:27	Kitware Robot	Status	assigned => resolved
2016-06-10 14:27	Kitware Robot	Resolution	open => moved
2016-06-10 14:31	Kitware Robot	Status	resolved => closed