UnauthorizedAccessException

tomcat2001 · Post by **tomcat2001** » Thu Feb 09, 2006 3:27 pm

I'm using Vault 3.1.5 with CruiseControl.Net. And randomly when it's getting a latest version of the source code we get the following error (it's not always on the same file, but it's generally one of our project files.

<vault>
<error>
Access to the path "C:\Code\Support\Messages\Messages.csproj" is denied.
</error>
<exception>
System.UnauthorizedAccessException: Access to the path "C:\Code\Support\Messages\Messages.csproj" is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String str)
at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite)
at VaultClientOperationsLib.ClientInstance.ProcessFile_NonWorkingFolder(String tempFile, VaultClientFile file, VaultResponseGetFile response, String ancestorFullPath, String ancestorDiskPath, SetFileTimeType setFileTime, MakeWritableType makeWritable, MergeType merge, OverwritePrompt PromptData)
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)
at VaultClientOperationsLib.ClientInstance.GetToNonWorkingFolder(VaultClientFile[] files, Boolean forceLatest, Boolean overwrite, MakeWritableType makeWritable, SetFileTimeType setFileTime, String ancestorFullPath, String ancestorDiskPath, OverwritePrompt PromptData)
at VaultClientOperationsLib.ClientInstance.GetToNonWorkingFolder(VaultClientFolder folder, Boolean recursive, Boolean forceLatest, Boolean overwrite, MakeWritableType makeWritable, SetFileTimeType setFileTime, String ancestorDiskPath, OverwritePrompt PromptData)
at VaultCmdLineClient.VaultCmdLineClient.ProcessCommandGet(ArrayList strItemArray)
at VaultCmdLineClient.VaultCmdLineClient.ProcessCommand(Args curArg)
at VaultCmdLineClient.VaultCmdLineClient.Main(String[] args)
</exception>
<result success="no" />
</vault>

The command that appears to be run from within CruiseControl.Net is:
C:\Program Files\SourceGear\Vault Client\vault.exe get $ -destpath C:\Code -merge overwrite -setfiletime checkin -makewritable

Any help on this is appreciated.

ian_sg · Post by **ian_sg** » Thu Feb 09, 2006 4:22 pm

Most of the time issues like this are related to virus scanners installed on the machine. Is that a possibility here?

If not, what version of CruiseControl are you using?

tomcat2001 · Post by **tomcat2001** » Thu Feb 09, 2006 4:31 pm

We do not have a virus scanner running. We are actually running this under a Virtual Private Server system. I don't think this is the actual issue, but just in case.

We are running CruiseControl.Net version 1.0 build 1.0.0.1251

dan · Post by **dan** » Thu Feb 09, 2006 8:13 pm

Something is holding a lock on the file being retrieved. You might want to check whether there are background Norton or McAfee processes/services on that machine - scanning software is almost always the culprit with errors like this.

I also noticed that you are using -destpath in the command line, which specifies a non-working folder, and will overwrite whatever is there. It would be better to either do the -destpath to an empty folder, or leave -destpath off entirely, in which case Vault would not retrieve files that are already up to date in the working folder.

tomcat2001 · Post by **tomcat2001** » Fri Feb 10, 2006 8:39 am

Let me reiterate, there is NO virus scanner running on this system. I am only using the destpath option because of the way that CruiseControl works. It has some issues with just using the default working directory so it uses the destpath, but the path is really the working directory.

ian_sg · Post by **ian_sg** » Fri Feb 10, 2006 8:51 am

We have provided some fixes and enhancements to the CC.NET project that are supposed to be included in a build Real Soon Now, which probably fixes the working folder issues you're mentioning.

Regarding the access violation, there's got to be another process using the files in question. Given the scenario here, my first guess would be VS.NET or another compiler. Is that a possibility?

dan · Post by **dan** » Fri Feb 10, 2006 8:53 am

If it isn't virus scanning software, it is some other process holding a lock on the file.

What issues have you seen with the CLC and working folders? I wouldn't recommend using -destpath to a working folder, as it has to overwrite every file in the working folder (and back up the existing copies), which probably increases the likelihood of seeing locked files and such.

Note that recently we added a -workingfolder option to the command line client GET command which allows you to temporarily switch to a different working folder. Would that help address the issues you are seeing in CC?

tomcat2001 · Post by **tomcat2001** » Fri Feb 10, 2006 8:54 am

Well I think that the VS.Net compiler is the culprit, but I haven't figured out how yet. I noticed that there were 2 instances of devenv.exe running, but I don't think an actual integration was running. I'll keep an eye on this to see if those show up anymore or not. So that's likely the culprit. I look forward to the new version that fixes the Working Folder problem.