Team Build: The path 'Path' is already mapped in workspace 'workspace' error even after deleting all workspaces on build agent

Question

I have this problem when I queue a build. The build dies with the error

The path C:\[Path]\Sources is already mapped in workspace [Server Name].

the same as this question. but I've removed all the workspaces on the build agent by running this command:

tf workspaces /remove:*

and also by deleting the TFS cache folder. I've also restarted the server, but the error keeps happening on each build.

Answer 1

Ok, so the solution ended up being fairly similar to what YeahStu posted on here. I changed the Build Agent's working directory from

$(Temp)\UI\$(BuildDefinitionPath)

to

$(Temp)\UI\$(BuildDefinitionPath)\$(BuildDefinitionID)

What is odd is that the other build agent we have is still running in $(Temp)\UI\$(BuildDefinitionPath) and working fine. The only difference between the two agents is the the one that stopped working had Visual Studio 2010 RC installed on it, while the one that's still working has VS2010 Beta2 on it. No idea why this should make a difference.

Answer 2

I think the issue appear only if you have more then one build agents on one build box.

Answer 3

http://blog.devaffair.com/2011/11/path-is-already-mapped-in-workspace.html

Well, actually this problem has been solved in several other questions in this site, but I'll post my answer again :)

This link will direct you to a blog which will probably solve your problem the fastest

Answer 4

I think your problm maybe to do with having 3 build agents that are not tagged. I think the workspace, if left behind, is deleted by the agent that is doing the build. If it is a different agent to the agent that created the workspace then there will be obvious issues.

So to fix the issue you need to do the following. Name One agent the Default Agent. This will have not tags. In the other two agents, in properties add a tag for the agents, One for each agent and select that.

Now any build that is executed that has no tag set will always use the Default Agent.

To get a build to use one of the other agents, open the build definition and goto the advanced section in Process.

Open the Agent Settings and select the ellipsis in Tags Filter and enter a tag of the same name for the the tag entered on the build agent you want to use.

You may need to clear up the workspaces before the first run.

Doing the above allows you to control what build agent is used for each build definition, and therefore should also stop your workspace issue.

Answer 5

I was able to remove the workspace. On the build server do this:

Download psExec from sysinternals.
http://technet.microsoft.com/en-us/sysinternals/bb897553

Open cmd as Administrator.

Run psexec to open cmd as Network Service.
psexec -i -u "nt authority\network service" cmd.exe That opens another cmd window that "nt authority\network service" is using.

Run a “whoami” to make sure you’re now "nt authority\network service".

Open visual studio by typing devenv.

Within visual studio\team explorer, Connect to the source control server

Within visual studio\ source control explorer, throw away the offending workspaces.

I have no idea why, but the tf workspaces /remove was not working for me.

Answer 6

More info about the working directory property here:

http://msdn.microsoft.com/en-us/library/bb399135.aspx

However, in the RTM version "$(HOMEDRIVE)" isn't recognized. Might be because of the casing; haven't tested it, so be aware of that flaw in the docs.

Answer 7

I had the same issue - it was running fine until I installed VS2010 on the build agent. Adding the BuildDefinitionId fixed it, but it is strange that installing VS2010 would mess up the workspaces that are already set up and running.

Answer 8

Changed to

$(Temp)\UI\$(BuildDefinitionPath)\$(BuildDefinitionID)

makes it working but not for 100% situations. Every time when build failed to complete (e.g. some error in source-codes or something), then after fixing error and trying to run team build again it fails on "Workspace XYZ is already mapped ...", then i must manually delete this workspace mapping by "Team Foundation Sidekick 2010" and run team build again to be success. Next time executing same team build more than once are successfully builded, but until some team build fail according to some error in source code, then it again start to throw "workspace mapping" errors.

It seems to me that TFS 2010 has some bug when some team build fails, it does not clear/delete workspace used, or something similar.

Have someone same problems experiencing?

Answer 9

==== Visual Studio 2010 ====

I wasn't able to see the "faulty" workspaces in TFS Sidekick and thus could not remove them. The steps that David Osborne described pointed me to the right direction. I was able to see the "faulty" workspaces in TFS Sidekick and finally I could remove them.

On the build server do this:

Download psExec from sysinternals.
http://technet.microsoft.com/en-us/sysinternals/bb897553

Open cmd as Administrator.

Run psexec to open cmd as Network Service.
psexec -i -u "nt authority\network service" cmd.exe That opens another cmd window that "nt authority\network service" is using.

Run a “whoami” to make sure you’re now "nt authority\network service".

Open visual studio by typing C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.

When asked use the login from the TFS buildagent account to start Visual Studio.

Within visual studio\team explorer, Connect to the source control server

Within visual studio\ source control explorer, throw away the offending workspaces.

Delete the "faulty" workspaces with TFS SideKick.

Now the issue was solved.