Somehow I have ended up with a "ghost" workspace. It doesn't show up in Visual Studio under Manage Workspaces. When I connect to VS Team Services and open source control explorer it pops up an error dialog with TF14061 ("The workspace does not exist")
When I try to delete it from sidekicks it also results in TF14061:
tf vc workspace "MYCOMPUTER;My Name" /delete /collection:https://me.visualstudio.com/defaultcollection
TF14061: The workspace MYCOMPUTER;My Name does not exist.
I can see the workspace when searching for shelvesets on my computer:
tf workspaces /computer:MYCOMPUTER /owner:* /collection:https://me.visualstudio.com/defaultcollection
Result:
=======================================================================================================================
Workspace : MYCOMPUTER
Owner : My Name
Computer : MYCOMPUTER
Comment :
Collection : https://me.visualstudio.com/defaultcollection
Permissions: Private
Location : Server
File Time : Current
Working folders:
$/: C:\local
Simply searching for the workspace by workspace name or by owner name does not return the workspace at all.
I am trying to create a new workspace and map it to the same folder but I'm getting the error that this folder is already mapped in another workspace.
How can I remove this phantom workspace?
Edit: Additional information It appears the security tokens for these duplicate workspaces are different even though the owner is the same. One matches the my Azure AD account, the other matches my Microsoft Account. This is odd, since my Microsoft Account has no permission on this server.
Note: I'm using Visual Studio Team Services.
You can use tf workspaces command to get detailed XML info for all workspaces, including owner uniqe id and owner alias user names:
tf workspaces /owner:* /format:xml
Sample output:
<Workspace computer="computer" name="wrkspacename" ownerdisp="Some Name"
ownerid="S-1-5-00-0000000000-0000000000-000000000-0000"
ownertype="System.Security.Principal.WindowsIdentity"
owner="12345678-90ab-cdef-1234-567890abcdef"
owneruniq="12345678-90ab-cdef-1234-567890abcdef">
<Comment />
<Folders>
<WorkingFolder local="C:\Folder" item="$/Folder" />
</Folders>
<LastAccessDate>2019-01-01T01:02:03.456+00:00</LastAccessDate>
<OwnerAliases>
<string>SERVER\Name</string>
<string>Name</string>
<string>Some Name</string>
</OwnerAliases>
</Workspace>
You can then try some of the OwnerAliases as owner to delete workspace or directly use owneruniq:
tf workspace /delete wrkspacename;12345678-90ab-cdef-1234-567890abcdef
Buck is most certainly right about the identity issue. I stumbled upon it yesterday after an Azure AD migration. Fortunately there is a way around. Here is the PowerShell solution that I found with the help of the Team Foundation .NET assemblies. (For the record I am using PowerShell version 5.0.)
Add-Type -AssemblyName 'Microsoft.TeamFoundation.Client, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' Add-Type -AssemblyName 'Microsoft.TeamFoundation.VersionControl.Client, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
$uri = 'https://me.visualstudio.com/defaultcollection' $tfs = [Microsoft.TeamFoundation.Client.TfsTeamProjectCollectionFactory]::GetTeamProjectCollection($uri) $vcs = $tfs.GetService([Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer])
$vcs.QueryWorkspaces('WorkspaceName', $null, $null) | % QualifiedName
You might have a look at the QueryWorkspaces online help. If the call to QueryWorkspaces()
does not return anything, which is the case if you only pass a computer name, you might have to issue it this way instead:
Invoke-Method -InputObject $vcs -MethodName 'QueryWorkspaces' -Arguments $null, $null, 'ComputerName' | % QualifiedName
It seems to be dued to the fact that $null
cannot be passed directly from within PowerShell. I had the issue before and this post helped me (but it seems to be now retired).
TF.exe
to delete the workspace (remember it is PowerShell, hence the --%
):tf workspace /collection:$uri --% /delete 'WorkspaceName;11111111-2222-3333-4444-555555555555'
Notice that you might as well call the Delete()
method on the Workspace object returned by the QueryWorkspaces()
issued against VCS...
HTH
What's happened here is that you have two identities with the same display name. One of the identities is an old identity that was created with your Microsoft Account (MSA). The new identity is your Azure AD account (AAD). Internally, they have different GUIDs. When you run the tf command workspace /delete command with the owner name that was displayed, the ambiguous display name is resolved to the current identity (AAD) rather than the old identity (MSA) that actually owns the workspace.
I can't remember for sure, but it's possible you could run tf workspace /delete and use a wildcard for the owner if you are certain that you can safely delete all workspaces for any owner with that workspace name (be very careful to make sure you don't delete someone else's workspace).
I'd recommend trying the Attrice Sidekick for TFS and using the manage workspaces functionality there to see if you can delete the workspace under your old identity. That will be the safest and easiest route if it works.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With