vault / ccnet BUILD EXCEPTION

[Dhominator]

vault: 3.1.8
ccnet: 1.1.0.2376

Anyone else experiencing this or know if it is related to cleanCopy==true?

Due to the CL client not deleting files locally (-performdeletions) I changed the ccnet vault source block to include cleanCopy true. Coincidently or not... now getting intermittent build exceptions (see below). The exception is ocurring before the nant script is run. Am unclear on what directory isn't mt and what might be locking it.

Ideas?

Best,
/jhd

Code: Select all

BUILD EXCEPTION

Error Message: 	System.IO.IOException: The directory is not empty. at System.IO.__Error.WinIOError(Int32 errorCode, String str) at System.IO.Directory.DeleteHelper(String fullPath, String userPath, Boolean recursive) at System.IO.Directory.Delete(String fullPath, String userPath, Boolean recursive) at ThoughtWorks.CruiseControl.Core.Util.IoService.EmptyDirectoryIncludingReadOnlyObjects(String directoryPath) at ThoughtWorks.CruiseControl.Core.Util.IoService.EmptyDirectoryIncludingReadOnlyObjects(String directoryPath) at ThoughtWorks.CruiseControl.Core.Util.IoService.EmptyDirectoryIncludingReadOnlyObjects(String directoryPath) at ThoughtWorks.CruiseControl.Core.Util.IoService.EmptyDirectoryIncludingReadOnlyObjects(String directoryPath) at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Vault317.GetSource(IIntegrationResult result) at ThoughtWorks.CruiseControl.Core.Sourcecontrol.VaultVersionChecker.GetSource(IIntegrationResult result) at ThoughtWorks.CruiseControl.Core.Sourcecontrol.FilteredSourceControl.GetSource(IIntegrationResult result) at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest request)

Project: 	SomeProject
Date of build: 	7/5/2006 11:59:42 AM
Running time: 	00:00:10
Integration Request: 	IntervalTrigger triggered a build (IfModificationExists)
Last changed: 	2006-07-05 11:51:51
Last log entry: 	

[Dhominator]

not much additional info in the ccnet log... the directory in question is the root directory for this build.

Code: Select all

2006-07-05 16:28:38,525 [ProjectRootDir:INFO] 1 modification detected.
2006-07-05 16:28:38,525 [ProjectRootDir:INFO] IntervalTrigger triggered a build (IfModificationExists)
2006-07-05 16:28:38,525 [ProjectRootDir:DEBUG] Cleaning out source folder: g:\SomeBuildServerPath\Source\ProjectRootDir
2006-07-05 16:28:47,072 [ProjectRootDir:ERROR] INTERNAL ERROR: The directory is not empty.

----------
System.IO.IOException: The directory is not empty.

<snip>

[ian_sg]

jhd,

We've been using cleanCopy in all of our builds for over six months now, and haven't seen this. My guess is there's a process locking these files such that they can't be deleted by the cc.net process.

Do you have multiple projects build in overlapping directories, such that they might be locking files and interfering with one another? Are there other processes run during your build that might not have completed (and are therefore still locking files) when a new build kicks off? What files are left in the directory when this error occurs?

Process Explorer is reputedly a good tool for determining what process has files locked, though it's been many years since I used it.

[Dhominator]

Understood.

Previously I added some script to kill Wise for Windows Installer... which takes a while to exit (5-20s my observation). This is verified working, can now delete it's .tmp files. No other obvious activity. WfWI is not very friendly in terms of automated builds.

Single project build, no overlapping anything. Have emailed devs re: No Forced Builds... as I've been unable to check out the directory before someone kicks off another.

ProcessExplorer is excellent, the new version adds memory and io graphs, use it all the time. Have it "runas" the build account to see processes spawned during the build. Indexing is turned off for the drive. Checking virus protection. Likely something along those lines.

Guess I'll load up filemon and see what's what... will be a mountain of output but running out of ideas

/jhd

[Dhominator]

Am now suspecting access to directories via hidden administrative share as a possible culprit. Will lock down the directory perms.

/jhd

[exortech]

this issue should be resolved as of ccnet build 1.1.0.2460

http://jira.public.thoughtworks.org/browse/CCNET-740