Runner fails because "filename too long" on Windows

My build creates a quite long path, I mean longer than the default 260 characters from windows.
Windows is configured with “long pathname” option so my build is successful locally.

On runner side, first build is successful as well. (Build is running in Win 10 power shell)

On the 2nd build, the runner starts to deletes each file from previous build one after the other, but then fails because the runner fails to delete my long pathname files.

I get this error:
“warning: could not stat path ‘my_long_path/xxx/xxx’: Filename too long
ERROR: Job failed: exit status 1”

Any idea how to fix that ?
Thank you

Long path tool was always there for me in this type of problem. I’ve been using it for months now and it is really helpful

Thanks for the insight, @Juan_Miller! and welcome to our forum!

@Chris1, if the above input was helpful, please mark it as the answer!

My idea is to shorten the path name for each directory, this always works with, but if you just need to let the structure as it or of you have many paths, you can just use the Long Path Tool or Gs RichCopy 360, google both

Hi @ Juan_Miller, can you give more details? Is there some cmd in powershell or in gitlab-ci?
Thank you

I’m a bit late to the game on this issue but using GitLab Enterprise Edition 14.4.0.ee, my build is having this long file issue with my build on a Windows 10 powershell runner like @Chris1. I enabled long paths in Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem by setting the Enable Win32 long paths to enabled. I even rebooted my windows vm to no avail. Do I need to use a Long Path tool as mentioned by @lianbogdady ?

Just wondering if the other posters on this issue have a better solution because this is blocking my progress on setting up GitLab.
@Juan_Miller
@lindsayk
@ruicruz

Thanks!
Ann

Also running into this, it appears to be that git provides the checkout with its own git config from a template.

Gitlab runner has:

• HKLM:/SYSTEM/CurrentControlSet/Control/FileSystem/LongPathsEnabled is set to 1,
• core.longpaths is set to true,
• I am able to clone the same branch/commit that is failing using the command line as the gitlab runner user,

The problem appears to be that builds/$runner/$conc/$group/$proj.tmp/git-template/config does not specify core.longpaths = true and I don’t see a way to assert it.

I assume using before_script in .gitlab-ci.yml?

before_script:
  - git config --system core.longpaths true

Following this suggestion.

I got it working for the moment by just adding core.longpaths to the $project.tmp/git-template/config file and repulling, that seemed to work. But I’ll try adding it to the before script when it falls over next time I flush the caches

On my side, nothing was working (I guess I did something wrong) but then I used the steps here, and it worked:

Run a Powershell (or cmd) as Administrator and type:

git config --system core.longpaths true

This will resolve the problem for all projects runned on this Runner.

I agree. Long Path Tool has also helped me save my time and solve this kind of problems.

Filename too long is so irritating, it always gets on my nerve. However, for some months, I have been using LongPath Tool and it has become easy now.

Filename too long can be very irritating, in this situation one can rely on tools only. I use Long Path Tool.