IO error Cruise Control .net 1.5

[grs]

I updated my ccnet installation today to 1.5, and the product appears to work when run at the command line.

Unfortunately, it does not work while operating as a service. This is the most recent error (in all projects):
Error Message: System.IO.IOException: The file exists.

at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.__Error.WinIOError()
at System.IO.Path.GetTempFileName()
at VaultClientOperationsLib.ClientInstance.ProcessGetFileRequests(GetFileInfo[] infos, MakeWritableType makeWritable, SetFileTimeType setFileTime, MergeType merge, Boolean updateHiddenFilesOnly, String ancestorFullPath, Boolean flat, String ancestorDiskPath, OverwritePrompt PromptData, Boolean isLabelGet, String currentPathToLabelItem, Int64 labelID, Boolean isRetry, Boolean isGetByDisplayVersion)
at VaultClientOperationsLib.ClientInstance.Get(VaultClientFolder[] folders, Boolean forceLatest, MakeWritableType makeWritable, SetFileTimeType setFileTime, MergeType merge, OverwritePrompt PromptData)
at VaultClientOperationsLib.ClientInstance.Get(VaultClientFolder folder, Boolean recursive, Boolean forceLatest, MakeWritableType makeWritable, SetFileTimeType setFileTime, MergeType merge, OverwritePrompt PromptData)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.FortressClient.GetVersion(String repositoryFolderPath, String workingDir, Int64 folderVersion, Boolean useWorkingDir, Boolean deleteItemsThatAreNotInTheRepository)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.FortressVaultSourceControl.GetSource(IIntegrationResult result)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Build(IIntegrationResult result)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest request)

Rather than upgrading, I completely replaced the ccnet installation, keeping only my project config file to avoid any version mismatch issues - although I did leave the working and artifact directories intact.

Has anyone else seen this type of behavior?

[lbauer]

What version of Fortress are you using? If you're on Fortress 2.0.x, you can use our new plugin for CCNET 1.5. It's available from our downloads page:

http://www.sourcegear.com/fortress/downloads.html

[grs]

Linda,

Fortress 2.0.3, new 1.5 ccnet plugin, and the released version of ccnet 1.5 is the platform.
Having had several problems with both ccnet and the plugin earlier, I installed the fortress client, ccnet, and the fortress plugin from scratch, retaining only my ccnet.config file.

The service is set to run as a domain user with local administrator on the build machine, rather than the default local system context. I am logged in as that domain user, and am running ccnet successfully via the command line - that is how the build server is running at present.

However, when I stop the ccnet.exe process and start ccservice.exe under the same user, I receive the error I pasted into the original posting for every project.

Gregg

[lbauer]

This sounds like a permissions problem.

You mentioned our plugin, but it's still unclear whether you are running our CCNET plugin or the built in cc.net vault block.

[grs]

Linda,

I stepped back and observed this for a bit, but unfortunately find that it is still happening - although I can occasionally get 1 build out of the system while running as a service, it goes back into this failure mode quickly.

I am using your ccnet plugin here, not the vault block.

I agree that it sounds like a permission problem, albeit an apparently inconsistent one - any idea how I can find out which temp file is being attempted, so I can clean it up if necessary?

[lbauer]

Within the code ClientInstance.ProcessGetFileRequests(), the client will ask the server for file contents as a GET operation was invoked. Once the file starts coming down from the server, the client next opens a TEMP file to store the results.

It is in this spot that the failure occurs and the download for the GET fails.

We did a search on "the file exists" error, and found it can occur when there are too many files in a temp directory:
http://paulmaddox.net/2008/12/net-gette ... hrows.html

If this is relevant in your case, that could explain the intermittent nature of the problem.

Do you know what account the service is running as?

The service most likely needs to run as an account which has the capability to create a temp file (when running as a server). Once that has been determined, you might be able to go to that file and see what is going on in the %TEMP% directory for the CC.NET service.