1

We recently upgraded from TFS 2010 to TFS 2015. Everything appears to be fine post-upgrade, but we are getting the error "The item is locked in workspace (null);(null)." on some source control files. It looks like we have some orphaned locks that need to be tracked down and cleaned up, but the tbl_lock database table is not on the database, so the following select query won't work:

select * FROM tbl_Lock l 
LEFT JOIN tbl_PendingChange pc 
ON l.PendingChangeId = pc.PendingChangeId 
WHERE pc.PendingChangeId IS NULL

Does anyone know how to detect and remove these locks in TFS 2015?

I also installed the TFS power tools, and neither Visual Studio 2015 nor the power tools are picking up the locks.

Updated:

BTW, when I run the SELECT query to find out where PendingChangeId is NULL, I get back no rows. I think the trick is the LEFT JOIN. PendingChangeId would be NULL when tbl_Lock also had no record for the PendingChangeId on tbl_PendingChange (and thus the lock was orphaned). So I'd still need to know where the PendingChangeId should normally be joined to in TFS 2015, to identify which files have a lock that is bad. (Or where a workspace no longer exists, which may be another possible source for the issue.)

And I also still need to know how to clean up those bad locks. I'd prefer to do this using the tools, either via the GUI or the command line, but could also do this programmatically either using the API or the TFS Object Model files for TFS 2015.

I really would rather only touch the database directly as a last ditch resort. And I would also rather use tf vc destroy on the item as a last ditch resort as well, since that would wipe out all history on the files.

Update 2

Aha! I think I found a way to identify the files, and it looks like my thinking for what happened may be correct. Unfortunately, I had to probe the database using a READ UNCOMMITTED query to find the information. I couldn't get at this information programmatically or using the tools. (They all showed or acted like the file is not checked out.) The query that I used on TFS 2015 was:

select pc.* from tbl_PendingChange pc 
left join tbl_Workspace ws on pc.WorkspaceId = ws.WorkspaceId 
where ws.WorkspaceId is null

This returned the three files that have the (null);(null) lock on our database, because the WorkspaceId listed on tbl_PendingChange does not exist anymore on tbl_Workspace.

How did this happen? Our CI server uses temporary TFS workspaces. I think what happened after the upgrade is that our CI server went to check out the file and apply an update to it. (For example, to increment version numbers as part of the build process.) It checked out the file, but failed to apply the update. (Our tools like working with Server workspaces, but it may have ended up with a Local workspace and thus the file was still checked in Local, but checked out on the Server. Thus the change to the file couldn't be applied.) The code that we are using performs a workspace.Delete operation when the process completes, so the workspace was deleted - even though the workspace still had the file checked out! So this created an orphan record on tbl_PendingChange that isn't linked to any Workspace, and thus the file is still locked with pending changes. But the GUI and tools aren't seeing it as such, because they're not realizing the pending change's workspace is non-existent.

So this brings me back around to how do I fix this? If someone knows of a way to get at these orphaned pending changes, I'd appreciate it. I tried using:

        TfsTeamProjectCollection tfsTeamProjectCollection = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri(szProjectUri));
        VersionControlServer versionControlServer = tfsTeamProjectCollection.GetService<VersionControlServer>();

        string[] items = new[] { ... server item path ... };
        PendingSet[] queryPendingSets = versionControlServer.QueryPendingSets(items, RecursionType.None, null, null);
        PendingSet[] getPendingSets = versionControlServer.GetPendingSets(items, RecursionType.None);

but these aren't finding the orphans.

Update 3

I finally installed Team Foundation Sidekicks 2015 and gave it a try - status tool specifically, but then other tools. It's finding pending changes, but not the orphaned ones.

Jeff
  • 627
  • 7
  • 22

3 Answers3

1

You can use Team Foundation Sidekicks to search and undo lock by following steps:

  1. Install the tool and launch it.
  2. Select TFS server to connect.
  3. Select "Tools\Status Sidekick".
  4. Set the "Search criteria" for the information you want.
  5. Click "Search" button.
  6. Select the locked file and click "Unlock lock" button.

enter image description here

Eddie Chen - MSFT
  • 29,708
  • 2
  • 46
  • 60
  • I have attempted to download the TFS 2015 version of this program, but I am receiving a "The signature of this program is corrupt or invalid." error. – Jeff Mar 04 '16 at 21:11
  • @Jeff Which link are you using? – Eddie Chen - MSFT Mar 07 '16 at 06:55
  • http://www.attrice.info/downloads/TF_Sidekicks_6.0.0.msi This link is on their page: http://www.attrice.info/downloads/index.htm#tfssidekicks2015 which I reached by clicking the "Download version 6.0 of Team Foundation Sidekicks (only for Visual Studio© 2015, Team Foundation Server 2015 and Team Foundation Service)." link on the page you linked to. – Jeff Mar 07 '16 at 20:35
  • @Jeff Try with the steps here: http://answers.microsoft.com/en-us/ie/forum/ie10-windows_7/the-signature-of-this-program-is-corrupt-or/90ff01cd-41f1-426d-96a5-fb1a6852e8e2?auth=1 – Eddie Chen - MSFT Mar 08 '16 at 07:45
  • Nope, none of those worked. I checked and unchecked the box and even reset Internet Explorer, and I'm still getting the corrupt signature error. – Jeff Mar 08 '16 at 20:33
  • I think I see what the problem is. I downloaded the MSI with Firefox and then brought up the properties for the file. When I went to the Digital Signatures tab, it has Microsoft Corporation as the name of the signer in the signature list. When I bring up the details, it indicates that "The digital signature is not valid." When I click on View Certificate, it says "The digital signature of the object did not verify." It says it was issued to Microsoft Corporation, and Issued By Microsoft Code Signing PCA. So it looks like the digital signature is invalid according to my system. – Jeff Mar 08 '16 at 20:45
  • Okay, I finally installed this and gave it a try. It's also not finding these orphaned pending changes with no workspace. – Jeff Mar 11 '16 at 17:11
0

You can using below command to undo the pending changes:

tf undo "file_path" /workspace:workspace_name

Or you can just use below command to delete the old workspace

tf workspace /delete /server:your_tfs_server workspace;username

From Visual Studio 2015 GUI：

File -> Source Control -> Advanced -> Workspaces...

In the dialog that came up, check "Show remote workspaces" and the locked workspace came up in the window. Then selected it and click "Remove".

Details about it, please check this blog and more ways to resolve this you can refer the similar question: What do you do if the file in TFS is locked by someone else?

Update:

According to the sql query. It's looking for .PendingChangeId IS NULL . You can use the similarly tbl_PendingChange under collection database. However, it's not a commendatory method. Since operate directly in the TFS database is not recommended.

Community
  • 1
  • 1
PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62
  • But how do I represent the (null);(null) workspace? I also can't see it as a remote workspace, even if I'm logged in as a project collection administrator. – Jeff Mar 01 '16 at 15:54
  • I also tried putting (null) and * and nothing into the GUI, and it tells me either the ID is not found or that I need an owner. – Jeff Mar 01 '16 at 16:00
  • I also tried just ; and (null);(null) and *;* in the commands, and none of those are working either for tf vc undo. When I list the workspaces with tf workspaces, I'm also not seeing a (null);(null) workspace. – Jeff Mar 01 '16 at 16:01
  • That last ; should have been star semicolon star. – Jeff Mar 01 '16 at 21:06
  • Did you found the solution from this blog https://blogs.msdn.microsoft.com/chandrur/2010/09/21/orphaned-locks-in-tfs/? For TFS2015, there is no table `tbl_lock`. Definitely, select query won't work. – PatrickLu-MSFT Mar 02 '16 at 08:12
  • According to the sql query. It's looking for `.PendingChangeId IS NULL` . You can use the similarly `tbl_PendingChange` under collection database. However, it's not a commendatory method. – PatrickLu-MSFT Mar 02 '16 at 08:17
  • Yes, that's where I originally found this query. However, I changed the DELETE to a SELECT to see if I could identify which files have this issue, but found there was no tbl_lock on the database. – Jeff Mar 02 '16 at 17:56
  • BTW, when I run the SELECT query to find out where PendingChangeId is NULL, I get back no rows. I think the trick is the LEFT JOIN. PendingChangeId would be NULL when tbl_Lock also had no record for the PendingChangeId on tbl_PendingChange (and thus the lock was orphaned). So I'd still need to know where the PendingChangeId should normally be joined to in TFS 2015, to identify which files have a lock that is bad. And I also still need to know how to clean up those bad locks. – Jeff Mar 02 '16 at 18:02
0

The following command has cleared up the pending changesets that were orphaned:

tf vc destroy <itemspec> /startcleanup

After running this command, the file was able to be added back to TFS, and the file could be checked in and out and edited as normal. Running the query:

select pc.* from tbl_PendingChange pc 
left join tbl_Workspace ws on pc.WorkspaceId = ws.WorkspaceId 
where ws.WorkspaceId is null

also showed that the pending changeset record related to this file was gone as well.

Microsoft's documentation on this command can be found at https://msdn.microsoft.com/en-us/library/bb386005.aspx. Before using this command, you should review the documentation carefully and be sure to understand the consequences of using it.

Because this command permanently removes files and potenally all history from TFS - and does so recursively - you need to take precautions and be absolutely certain that you are targeting the command correctly. So before using this command, I would recommend taking the following additional precautions:

  1. Stop all user and external accesses to TFS and any other software that may be running from the machine.
  2. Make sure to run a full backup of TFS and any other databases located on the machine.
  3. If you can, take a snapshot in time of the server.

That way if something goes horribly wrong, you will have one or more points to fall back on.

Jeff
  • 627
  • 7
  • 22