• Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-client-plugin
    • None
    • OS: Windows
      Jenkins: 2.73.2
      Git_client_plugin: 2.5.0

      Git has a limit of 4096 characters for a filename, except on windows when git is compiled with msys. It uses an older version of the windows api and there's a limit of 260 characters for a filename.
      As mentioned in the Git Bash wiki, the `core.longpaths` config option tells git to use the UNC file paths (i.e. prepend `\\?\`). This works as long as the base path isn't too long.

      Please, add an option to run `git clone` with a `-c core.length true` parameter.

          [JENKINS-47609] Add an option for a long path

          Mark Waite added a comment -

          alkush21 have you confirmed that setting core.longpaths has the desired result? You should be able to set it globally on the agent as a temporary test to confirm it has the desired behavior. I've not seen any net positive result from setting core.longpaths.

          Before adding such a setting, I'd like to have confirmation from one or more users that it has the desired result (and does not have undesirable side effects).

          Mark Waite added a comment - alkush21 have you confirmed that setting core.longpaths has the desired result? You should be able to set it globally on the agent as a temporary test to confirm it has the desired behavior. I've not seen any net positive result from setting core.longpaths. Before adding such a setting, I'd like to have confirmation from one or more users that it has the desired result (and does not have undesirable side effects).

          markewaite I can confirm that this worked for me.
          I am not sure if it will have any side effects, so my suggestion is to make an option to have a long path (not a default). 

          Oleksandr Kushchak added a comment - markewaite I can confirm that this worked for me. I am not sure if it will have any side effects, so my suggestion is to make an option to have a long path (not a default). 

          I had

          • 41 chars "C:\Program Files (x86)\Jenkins\workspace\" + 75 chars + 8 chars "@script\" + 154 chars within worktree = 278 chars total = too much.
          • 28 chars "C:\Jenkins\agent1\workspace\" + 75 chars + 1 char "\" + 154 chars within worktree = 258 chars total = barely tolerable.

          The files with the longest names are *.datasource files generated by the service reference wizard of Microsoft Visual Studio. Those files are not used at build time, so it does not matter whether their working copies are accessible with normal Win32 calls, provided that the checkout succeeds and Jenkins is able to delete the directory later. (I believe the data binding features in the Windows Forms designer can use those files.)

          I tried the Short Workspace Path Plugin but, when a branch name in Bitbucket Server contained a slash character, it generated a workspace path that contained with a percent sign, which confused MSBuild. I then set core.longpaths in ~/.gitconfig files for the master and the agent, and that solved the problem.

          More recently though, JENKINS-42518 avoids the problem in the master altogether by not checking those files out from Bitbucket Server.

          Kalle Niemitalo added a comment - I had 41 chars "C:\Program Files (x86)\Jenkins\workspace\" + 75 chars + 8 chars "@script\" + 154 chars within worktree = 278 chars total = too much. 28 chars "C:\Jenkins\agent1\workspace\" + 75 chars + 1 char "\" + 154 chars within worktree = 258 chars total = barely tolerable. The files with the longest names are *.datasource files generated by the service reference wizard of Microsoft Visual Studio. Those files are not used at build time, so it does not matter whether their working copies are accessible with normal Win32 calls, provided that the checkout succeeds and Jenkins is able to delete the directory later. (I believe the data binding features in the Windows Forms designer can use those files.) I tried the Short Workspace Path Plugin but, when a branch name in Bitbucket Server contained a slash character, it generated a workspace path that contained with a percent sign, which confused MSBuild. I then set core.longpaths in ~/.gitconfig files for the master and the agent, and that solved the problem. More recently though, JENKINS-42518 avoids the problem in the master altogether by not checking those files out from Bitbucket Server.

          Mark Waite added a comment -

          kon Thanks for the note that setting core.longpaths resolved the issue for you.

          I think you may want to consider placing your workspace at a shorter path. For example, I place all my Windows agent paths at C:\J. That reduces the likelihood of Visual Studio generated paths will exceed the Windows limit.

          In general, I think that Windows prefers to not have working areas inside the Program Files tree, since they prefer to limit that tree to program installations, rather than working directories for those program installations.

          Mark Waite added a comment - kon Thanks for the note that setting core.longpaths resolved the issue for you. I think you may want to consider placing your workspace at a shorter path. For example, I place all my Windows agent paths at C:\J . That reduces the likelihood of Visual Studio generated paths will exceed the Windows limit. In general, I think that Windows prefers to not have working areas inside the Program Files tree, since they prefer to limit that tree to program installations, rather than working directories for those program installations.

          >I'd like to have confirmation from one or more users that it has the desired result (and does not have undesirable side effects).

          I can confirm that this works for me.

          Looking at the wiki page (https://github.com/git-for-windows/git/wiki/Git-cannot-create-a-file-or-directory-with-a-long-path) and the original commit (https://github.com/git-for-windows/git/commit/38b94fe15fb60e3871a166eec8cfd4265fee727f) it looks like there aren't any known issues, but if it's only enabled on the operations that need it, there shouldn't be any downsides (hopefully).

           

          >I think you may want to consider placing your workspace at a shorter path.

          With deep npm node_module dependency trees, we hit the limit even in `C:\` directly.

          Gibson Fahnestock added a comment - >I'd like to have confirmation from one or more users that it has the desired result (and does not have undesirable side effects). I can confirm that this works for me. Looking at the wiki page ( https://github.com/git-for-windows/git/wiki/Git-cannot-create-a-file-or-directory-with-a-long-path) and the original commit ( https://github.com/git-for-windows/git/commit/38b94fe15fb60e3871a166eec8cfd4265fee727f) it looks like there aren't any known issues, but if it's only enabled on the operations that need it, there shouldn't be any downsides (hopefully).   >I think you may want to consider placing your workspace at a shorter path. With deep npm node_module dependency trees, we hit the limit even in `C:\` directly.

          Mark Waite added a comment -

          I've marked this as "newbie-friendly" because it should be a relatively straightforward addition of a boolean option to the already long list of "clone options". The git client plugin already performs a git init to create a directory and then performs a git config to add remotes into that freshly created repository. With that option set, it would need to add a call to git config core.longpaths true before performing the fetch.

          Mark Waite added a comment - I've marked this as "newbie-friendly" because it should be a relatively straightforward addition of a boolean option to the already long list of "clone options". The git client plugin already performs a git init to create a directory and then performs a git config to add remotes into that freshly created repository. With that option set, it would need to add a call to git config core.longpaths true before performing the fetch.

          Rishabh Budhouliya added a comment - PR in git-plugin:  https://github.com/jenkinsci/git-plugin/pull/856 In git-client-plugin:  https://github.com/jenkinsci/git-client-plugin/pull/523

            Unassigned Unassigned
            alkush21 Oleksandr Kushchak
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: