• 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

          Oleksandr Kushchak created issue -
          Oleksandr Kushchak made changes -
          Description Original: 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 (which shouldn't be an issue for us).

          Please, add an option to run `git clone` with a `-c core.length true`.
          New: 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`.
          Oleksandr Kushchak made changes -
          Description Original: 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`.
          New: 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.
          Oleg Nenashev made changes -
          Component/s New: git-client-plugin [ 17423 ]
          Component/s Original: _unsorted [ 19622 ]
          Oleg Nenashev made changes -
          Assignee Original: Oleg Nenashev [ oleg_nenashev ] New: Mark Waite [ markewaite ]
          Mark Waite made changes -
          Assignee Original: Mark Waite [ markewaite ]

          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.

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

              Created:
              Updated: