SQ creating really long file names

  • Version: SonarQube Enterprise 8.8.0.42792, Azure DevOps (cloud hosted)
  • Error: ##[error]08:27:57.65 Failed to create an empty directory 'D:\[path]\[path]\221\.sonarqube\out'. Please check that there are no open or read-only files in the directory and that you have the necessary read/write permissions.
  • Detailed error message: Could not find a part of the path 'D__[path]_[path]_221_s_[appname]_src_web_apps_WebHealth_wwwroot_lib_jquery_validation_unobtrusive_jquery_validate_unobtrusive_js_288_23_FE_18_ada_min_max_min_min_max.ucfg'.
  • Steps to reproduce: intermittent, but happening pretty regularly now
  • Work-around: unknown

We started seeing this with one of our projects when it was updated from .NET Core 3.1 to .NET 5. However, that commit didn’t make any changes to the UI, which is where the file name is coming from.

The error is the same in all cases - when it happens - but there are different results I’m seeing.

  1. Most of the time, that absurdly long file name is there (in a pretty deep path). I cannot rename it or delete it in a normal manner, and end up having to use robocopy d:\ . /purge from the directory to delete it
  2. Some of the time, I go there and the directory is empty. I end up just deleting the .sonarqube folder for that pipeline, and the next time it runs, it is successful

Three questions: (1) why is it creating such long file names (including part of the path), (2) why is it creating such a deep path, which exacerbates the problem, and (3) what, if anything can I do about it to get these builds working consistently again?

The path where that long file name gets created looks like this:

D:\[path]\[path]\221\.sonarqube\out\.sonar\mod3\ucfg2\js

1 Like

We also started seeing this recently on the file which name/path didn’t change for couple years.
Our current version is 8.7.1
(since sonar is out of my control I can’t say version we were before 8.7.1)
This is pretty pressing thing, could you please recommend any workaround or maybe version where this is fixed already?

We’re seeing the same thing on our end. On Friday our scans started to randomly start failing when SonarCloud tries to write to files such as:

_agent__work_558_s_src_[path]_[filename]_21_16_FE_5901__sc__xc__lo__xc__xc__xc__xc__xc__ti__q__xc__xc__xc.ucfg

Log message:
Removing the existing directory: C:\agent\_work\558\.sonarqube\out Failed to create an empty directory 'C:\agent\_work\558\.sonarqube\out'. Please check that there are no open or read-only files in the directory and that you have the necessary read/write permissions. Detailed error message: Could not find a part of the path '_agent__work_558_s_src_[path]_[filename]_21_16_FE_5901__sc__xc__lo__xc__xc__xc__xc__xc__ti__q__xc__xc__xc.ucfg'.

Is there any way to fix this issue?

Deleting the /out folder allows a single build to run, but any subsequent builds will automatically fail. So it seems like there is something in the folder that it builds upon that takes it over some kind of limit.

I noticed that this folder becomes quite large too as it never seems to get cleaned up between builds. Could this be the issue?

Okay, in order to get this working I have had to add a powershell script to do some manual clean up before and after our builds. This, however, is not a good long-term solution.

For anyone else who comes across this issue before anyone can even take notice of this thread this fixed it for us:

Write-Output "Checking that path exists: $(Pipeline.Workspace)\.sonarqube\out"
if (Test-Path "$(Pipeline.Workspace)\.sonarqube\out") {
  Write-Output "Removing: $(Pipeline.Workspace)\.sonarqube\out"
  Remove-Item "$(Pipeline.Workspace)\.sonarqube\out\*" -Force -Recurse
  Remove-Item "$(Pipeline.Workspace)\.sonarqube\out" -Force
}

Edit because I can’t create more than three replies at once:

Update for everyone. That fix does not work. Eventually that script hit the same issue that the plugin had.

Checking that path exists: C:\agent\_work\113\.sonarqube\out
Removing: C:\agent\_work\113\.sonarqube\out
Remove-Item : Cannot remove item C:\agent\_work\113\.sonarqube\out\.sonar\mod78\ucfg2\js\_agent__work_113_s_src_[path]_[filename]_ts_21_16_FE_5902
__sc__xc__lo__xc__xc__xc__xc__xc__ti__q__xc__xc__xc.ucfg: Could not find a part of the path '_agent__work_113_s_src_[path]_[filename]_ts_21_16_FE_
5902__sc__xc__lo__xc__xc__xc__xc__xc__ti__q__xc__xc__xc.ucfg'.
At C:\agent\_work\_temp\b2f6eaae-90d3-481b-ade4-a1076c229ab9.ps1:6 char:3
+   Remove-Item "C:\agent\_work\113\.sonarqube\out\*" -Force -Recurse
+   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (_agent__work_11...xc__xc__xc.ucfg:FileInfo) [Remove-Item], DirectoryNotFoundException
    + FullyQualifiedErrorId : RemoveFileSystemItemIOError,Microsoft.PowerShell.Commands.RemoveItemCommand
##[error]PowerShell exited with code '1'.

Edit 2: Regedit to enable long file paths on each of our self hosted agents was what finally allowed us to fix this issue.

2 Likes

Hello,

sorry for the late reply, I created ticket to fix the long names on Windows

https://jira.sonarsource.com/browse/SONARSEC-2745

meet the same issue, it has been one year and still existed?

I’d like to have an update on this too.

We are seeing this here as well for some projects and the JIRA-ticket is not public so I can’t follow whatever happened to it. Does @saberduck have any insight on a possible solution?

Can also confim that manually removing the out-folder fixes the issue but only once.

Oh, and the regedit fix didn’t help us either.

I’m still having this issue as well (the really long names, and rmdir doesn’t want to delete them all), but I’ve had success so far with this hacky workaround:

  1. Create an empty folder somewhere on your drive
  2. Add a robocopy step to the start of the build.

robocopy /MIR d:\EmptyFolderKeepThis {buildDirectory}.sonarqube\out

Ideally the actual problem will get fixed, but hopefully this helps in the meantime.

hello,

this issue was fixed some time ago. Which version of SQ are you using? Can you please try with the latest 10.1 or LTS 9.9?

Hello,
I am with the same issue (c# analysis), we are using version 10.0
Any fix for this issue?

Thank you!