14

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.

Onots
  • 2,118
  • 21
  • 28
  • Did you try with "tf workspaces /owner:* /computer:MachineName /collection:https://xxxx.visualstudio.com" command to list the workspaces created by all users on your machine? – Eddie Chen - MSFT May 16 '16 at 05:29
  • @Eddie-MSFT Just tried it and it does show the workspace as well. – Onots May 16 '16 at 05:35
  • Did you check this link: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/2c0c6f49-95f1-4800-b4b8-76ccde81d007/tf14061-the-workspace-does-not-exist?forum=tfsversioncontrol? – Eddie Chen - MSFT May 16 '16 at 05:41
  • I did try to manually delete the cache and run tf workspaces /remove:* to remove the cache. Neither helped me out. I did not (yet) resort to renaming my computer. Note that the owner has my name but the workspace does not show up when I search by owner name. Also I can create a new workspace with exactly the same name. I just (obviously) cannot map to the same directory that is used in the "ghost" workspace. – Onots May 16 '16 at 05:44
  • If you can create a new workspace with the same name, then the owner name of the workspace should be different. – Eddie Chen - MSFT May 16 '16 at 06:12
  • That's what I thought. However I can create a (visually) duplicate workspace. Same text showing for name, owner and computer. – Onots May 16 '16 at 06:15
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/112024/discussion-between-eddie-msft-and-onots). – Eddie Chen - MSFT May 16 '16 at 06:31
  • This issue was resolved by Microsoft Tech Support. – Onots May 24 '16 at 02:37

3 Answers3

16

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
tibx
  • 840
  • 13
  • 20
  • Many thanks for this - the xml output finally helped me see the "Windows Live ID\foo.bar.company@outlook.com" format that I needed to use. – Ted Oct 14 '20 at 09:12
  • Note that in some cases you may need to explicitly specify the collection (seems necessary if using Azure DevOps) e.g. `tf workspace /delete wrkspacename;12345678-90ab-cdef-1234-567890abcdef /collection:https://dev.azure.com/{YourOrg}/}` – Nathan Dec 24 '20 at 01:45
2

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.)

  1. Load these assemblies into your PowerShell session (where the version matches your installation of Visual Studio; in my case Version=12.0.0.0 corresponds to VS 2013):
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'
  1. Connect to the VSTS version control server:
$uri = 'https://me.visualstudio.com/defaultcollection'
$tfs = [Microsoft.TeamFoundation.Client.TfsTeamProjectCollectionFactory]::GetTeamProjectCollection($uri)
$vcs = $tfs.GetService([Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer])
  1. Query for the workspace you want to delete and retrieve its qualified name:
$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).

  1. Pass the qualified name to 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

François
  • 90
  • 8
  • François, can I load the assemblies for VS 2017 as well in PS session? Like you showed above? If yes, do you know what version corresponds to VS 2017 and will the public key token remain the same? – SRP Sep 14 '20 at 08:06
  • Hi SRP, It should work for VS 2017 too, but with VS 2017 things have changed a bit. To be honest, I did not test it with VS 2017 but with VS 2019. You need to install the PowerShell module 'VSSetup' , available on PowerShell Gallery. Then you can execute the following lines of PowerShell to load the assemblies: see my next comment and [What's the equivalent of vswhere -find in vssetup.powershell](https://github.com/microsoft/vssetup.powershell/issues/52#issuecomment-533813553) for inspiration. – François Oct 06 '20 at 04:44
  • Get-VSSetupInstance | Select-VSSetupInstance -Require Microsoft.VisualStudio.TeamExplorer -Latest | Get-ChildItem -Recurse -Filter TeamFoundation -Directory | Convert-Path | Join-Path -ChildPath * | Get-ChildItem -Recurse -Include Microsoft.TeamFoundation.Client.dll, Microsoft.TeamFoundation.VersionControl.Client.dll | Convert-Path | ForEach-Object -Process { Add-Type -LiteralPath $_ } – François Oct 06 '20 at 04:56
1

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.

Buck Hodges
  • 3,342
  • 1
  • 19
  • 20
  • Your assessment is mostly correct. We did migrate from MSA to AAD over an year ago. All permissions for MSA were revoked though. The owner id matches of the zombie workspaces matches AAD. Somehow the security token contains the MSA id though. These workspaces cannot be removed with TF Sidekicks either. – Onots May 18 '16 at 01:11
  • If you'll open a free support case at https://www.visualstudio.com/en-us/support/cloud-services-assisted-support-vs, we'll work with you to get that fixed. – Buck Hodges May 20 '16 at 01:18
  • We've opened a support ticket a few days ago, and it seems to be worked on. – Onots May 20 '16 at 01:29
  • @Onots I have the same problem here... Have you found any solution to this? – mehrandvd Oct 21 '16 at 22:45
  • @mehrandvd There has been a regression in VSTS October 20th that was fixed (for most) on October 23st. See https://blogs.msdn.microsoft.com/vsoservice/?p=12605 – Onots Oct 25 '16 at 03:20
  • @Onots thank you.. I had to rename my computer and it worked. I'm not sure the renaming fixed the problem or the patch! – mehrandvd Oct 25 '16 at 10:04