0

I've recently started to encounter a problem with a new build agent that I have added to my TFS agent pool. The agent runs my build the first time without any problem. However, all subsequent builds fail with this error "##[error]The directory is not empty". This occurs on the initial startup of the build when it is trying to download files from TFS.

Keep in mind that I have set the "clean" option to true for the build and also set the Build.Clean variable to "all"

I've done searches online for this error and most of the info I am finding states that the directory is in-use and that is why it cannot be deleted. The strange thing is that I can manually delete the folder using Windows Explorer and there is no error reported of files in-use. Once I do that, the build will work again, but only on the first run. Why is it that the TFS vNext build cannot delete this folder? Is there a log that I reference that provides more details other than "directory is not empty"?

Ken
  • 72
  • 8
  • Does your build agent's service account have appropriate permissions to its working folder? It should be able to read/write/delete. – Daniel Mann Nov 21 '19 at 14:25
  • If it were a permission issue, wouldn't it be showing a different error? The agent service is running with NETWORK SERVICE account. I would think if it did not have appropriate permissions, it wouldn't be able to copy files to the folder, which it can do it the folder is empty. I will go ahead and add explicit permissions to the folder and see if has any effect. I won't know until tomorrow. – Ken Nov 21 '19 at 18:18

1 Answers1

3

You could set system.debug=true to enable verbose Debug Mode for TFS vNext Build.

In addition, you could also check the agent log under agent path\_diag path here.

enter image description here

If there are more information for troubleshooting.

Back to your issue, please try to stop you build agent service and restart again. Also update your build agent to latest version. Besides, you could also choose another driver such as D:\ or E:\ if you are using c:\agent\ which may do the trick.

PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62
  • Thanks for the info. I am thinking that maybe a path is too long because when I go to delete the folder using Windows Explorer, I get a message prompt indicating that the path is too long for the recycle bin and asks me if I want to permanently delete the files. If I say yes, the delete is successful. I am guessing that whatever vNext uses to delete the folder is likely failing because of this. – Ken Nov 22 '19 at 13:49
  • Also, I've checked the logs (without debug set) from last night's failed run. The entries are the same as what is reported in the web log. 01:44:10.156489 System.ComponentModel.Win32Exception (0x80004005): The directory is not empty I guess the next thing I can do is run the build with debug set to true, but for now I am going to have to switch back to my original agent because we are in a critical need to get the build to complete on a regular basis. – Ken Nov 22 '19 at 13:50
  • @Ken Thanks for your kindly update. That would be a strong possibility with long path issue according to your description. Actually, long path is quiet a common problem for build agent issue. Just met with a similar one recently https://stackoverflow.com/questions/58821034/powershell-on-target-machines-task-fails-with-an-error-in-tfs-2017-azure-dev-o . Not always generated error message is clever enough to point out root cause. For this kind of issue, you have to make sure you're not using paths that are too long. – PatrickLu-MSFT Nov 25 '19 at 10:39
  • I would also consider that as a possibility, however I don't understand why this same build can work on the original agent with the same path layout. The only difference between the new agent and the original agent is that of the OSs. The original agent is a Windows Server 2K8 R2 server, and the agent that I was trying to switch over to is a Windows 7 PC. I would have thought that the MAX_PATH issue would apply to both Windows OSs. If this was a path issue, I wish the error would indicate the offending path. – Ken Nov 25 '19 at 16:02
  • @Ken Of course it's just a guess, sill need your testing and verify. For this kind of troubleshooting issue. To be honest, it's a little hard to directly find root cause due to self-host agent environment. Since we could not reproduce and only could give a direction to narrow down the issue. About agent, both Windows 2008 R2 and Windows 7 PC meet the prerequisite. There should be no difference with Max_PATH. for both system. But sometimes, for some wired build issue, only reinstall agent fix the issue. As error would indicate the offending path. We will do better in this area. Thanks advice. – PatrickLu-MSFT Nov 26 '19 at 09:59