MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0010790CMakeCMakepublic2010-06-03 09:472010-11-08 11:16
ReporterAndras Lasso 2 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityrandom
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0010790: Random file copy failures on Windows 7
DescriptionFile copy in CMake and CPack fails randomly on Windows 7, causing failures in configuration file generation and package creation. The problem is reported by several people (e.g., see http://www.itk.org/Bug/view.php?id=9578 [^]).

Debugging the problem shows that the root cause of the failure is that the file size after the check fails (sometimes the source sometimes the destination file size is reported to be 0).

When the file copy is restarted with the same parameters and it is usually completed successfully.

The failure ratio seems to be higher if other disk operations are performed at the same time (file copy, directory listing refresh) or the copied file has not been accessed since a while. Similar problems are reported for other software (such as tortoisesvn), although disabling search indexing and antivirus seems to fix those problems (but maybe just decreasing the concurrent disk operations reduced the chance of failure to a negligible level).

My configuration is CMake 2.8.1 on Windows 7, 64-bit, and Visual Studio 9.0.30729.1. Search indexing and antivirus real-time protection is disabled on the build directory.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0009578closed Brad King ITK ITK Install fails on windows vista / windows 7 64 bit 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-06-03 09:47Andras Lasso 2New Issue
2010-06-03 09:49Andras Lasso 2Note Added: 0020908
2010-06-03 10:10Bill HoffmanStatusnew => assigned
2010-06-03 10:10Bill HoffmanAssigned To => Brad King
2010-06-03 11:40Brad KingNote Added: 0020913
2010-06-03 11:40Brad KingNote Edited: 0020913
2010-06-03 12:53Brad KingNote Added: 0020916
2010-06-03 17:43Andras Lasso 2Note Added: 0020920
2010-06-04 09:07Brad KingNote Added: 0020924
2010-11-08 11:16Brad KingNote Added: 0023060
2010-11-08 11:16Brad KingStatusassigned => closed
2010-11-08 11:16Brad KingResolutionopen => fixed
2010-11-08 11:17Brad KingRelationship addedrelated to 0009578

Notes
(0020908)
Andras Lasso 2   
2010-06-03 09:49   
Replacing the current file stream creation/read/write/close in SystemTools::CopyFileAlways with a simple Windows API call (CopyFile(source,destination,false)) seems to work very well. The copy is successful in all cases, build and package generation is completed without errors.
(0020913)
Brad King   
2010-06-03 11:40   
According to

  http://msdn.microsoft.com/en-us/library/aa363851(VS.85).aspx [^]

the CopyFile API call requires Windows 2000. We used to support Windows 98 but no longer need to do so.

However, the CopyFile function preserves the file modification time of the source file. This is desirable in some cases but is a change in behavior. A lot of code assumes (knows) that CopyFileAlways creates a new file. Since CopyFile also preserves permissions we will not be able to retroactively update the modification time for read-only files.

The stat-after-copy was introduced a long time ago:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=36189ce2 [^]

but the "more paranoid checking" message is not very informative as to why. I would think that if the return code of the file write was okay then we can trust that it worked. Perhaps the stat can just be removed.
(0020916)
Brad King   
2010-06-03 12:53   
This commit removes the stat:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c15ed329 [^]

and trusts that ofstream reports failure when necessary.
(0020920)
Andras Lasso 2   
2010-06-03 17:43   
I've tried a full Slicer build and package generation with the removed stat and it worked well! There were no copy errors any more!

When do you think this fix will be available in an official release?
(0020924)
Brad King   
2010-06-04 09:07   
It will be in 2.8.2; not sure when it will be out.
(0023060)
Brad King   
2010-11-08 11:16   
2.8.2 was released and contains this fix.
2.8.3 has since been released and still contains it.