TFS build broken - The directory is not empty on sources directory

Question

I am having a problem with my build (TFS2010). All has been well with this build recently until today where I am now getting an error pretty much as soon as the build starts:

Delete Sources Directory (00:00) The Directory is not empty.

I have looked on the server and I see \builds\1\myproject\sources\ is empty.. there is nothing in there at all! The error hints towards that not being the case, but it is empty for sure.

I wonder if it should not be empty in this case? Can anyone advise me on what course of action I might take on this to get the build running again?

This is the log of the failed build:

Overall Build Process
00:00
Update Build Number
00:00
Create the Drop Location
00:03
Run On Agent (reserved build agent Default Agent - server1)
00:00
Delete Test Results Directory
00:00
Delete Binaries Directory
00:00
Delete Workspace
00:00
Delete Sources Directory
 The directory is not empty.

Many thanks for any help!

Daimyo

Did you check your Source Settings Tab in your build? Make sure source control folder and Build Agent Control folder mappings are correct. check if anything changed recently. – Fey

Hey everything looks exactly as it did when it was working. Looking at a backup of the sources folder, I see that the first build that caused an error was complaining about permissions when deleting a file once the build was running (that caused the build to stop). The sources folder was then left incomplete and now is empty. – Daimyo

Manually delete the files inside e \builds\1\myproject folder and in our Build Process Tab section, change the clean Workspace to All if it is set as Output. Try the build. if it is working, change the clean workspace property to previous settings. – Fey

Answer 1

This usually happens if some other process has a handle on the file system. Explorer or a command prompt window is often the culprit.

Lathe

+1. Most common is just that you've opened a file explorer in a build folder, and just closing it will fix the issue. In the worst case (it's very unlikely to be this bad) you may need to reboot the server to flush out any unclosed handles. – Stephanestephani

A good tool for tracking down this issue is SysInternals Process Explorer (technet.microsoft.com/en-us/sysinternals). You can select "Find File Handle or DLL..." and enter a portion of the path to the build directory. It will tell you all processes that have handle on that path, so you know exactly what to close or kill. It has saved me a lot of unnecessary rebooting. – Sacroiliac

Answer 2

I had come across this issue as one of the deployment folder in the "c:\" was openend. so close the folder and start your build will work. thanks

Costermansville

Answer 3

except case when there are somebody took handle to subdir or any file in this dir - such error can happens when there are files in directory (or in any subdirectory) which path length > 260 symbols. In such cases you need to delete '\\?\C:\mydir' instead of 'C:\mydir'. About 260 symbols limit you can read here.

Magdamagdaia

Answer 4

Usually a file handle as mentioned above, although if you can't find the culprit deleting the "C:\agent_work\#NumberOfBuildDefinition#" will release this and mean the build can publish again.

This happens as your build definition, has a repository settings of "Clean" set to "true" and "Clean options" set to "Sources" so on every new build it's trying to remove all files from the folder in question.

Asphyxiant

Answer 5

For this problem, I just erase the deposit folder of the build that failed on the build server. I did not find anything in the event log. This is valid for those who have chosen to copy the output of the generation into a folder on the build server. My configuration: VS2015 / TFS2015 Build server: Windows Server 2008 R2

Jorgejorgensen

Answer 6

I got this very fast error multiple times one day, and in each case there was another tab or browser where I had my app (that I was trying to build) running. So there was no way for the build to get rid of files in use by the instance of the app running. The worst one I found was trying to do a build in Chrome and I finally found an instance of my app running in Edge. If worst comes to worst, reboot and that worked for me. Reboot kills the app instance you can't find.

Alpha