Filename too long in Git for Windows

Question

I'm using Git-1.9.0-preview20140217 for Windows. As I know, this release should fix the issue with too long filenames. But not for me.

Surely I'm doing something wrong: I did git config core.longpaths true and git add . and then git commit. Everything went well. But when I now do a git status, I get a list of files with Filename too long, for example:

node_modules/grunt-contrib-imagemin/node_modules/pngquant-bin/node_modules/bin-wrapper/node_modules/download/node_modules/request/node_modules/form-data/node_modules/combined-stream/node_modules/delayed-stream/test/integration/test-handle-source-errors.js: Filename too long

It is quite simple to reproduce for me: just create a Yeoman web application with the Angular generator ("yo angular") and remove node_modules from the .gitignore file. Then repeat the aforementioned Git commands.

What am I missing here?

Where do you read that that version should fix the long filenames? — iveqy, Mar 22 '14 at 09:19
Here is the pull request for the patch: https://github.com/msysgit/git/pull/122 — Papa Mufflon, Mar 22 '14 at 09:31
@PapaMufflon can you change the accepted answer to the one with more score? It just helped me a lot. — v.karbovnichy, Nov 02 '17 at 15:28
@v.karbovnichy please read my question carefully. I already ran the command in the top voted answer. But at the time I asked the question, the accepted answer was correct: msys still had this character-limitation. Now that limitation is gone and git config core.longpaths true works like it should. — Papa Mufflon, Nov 03 '17 at 16:33
Nowadays there is Linux in Windows in form of WSL2. No restrictions added. — Anssi, May 10 '21 at 06:26

score 1897 · Accepted Answer · edited Aug 03 '22 at 06:05

1897

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.

So as far as I understand this, it's a limitation of msys and not of Git. You can read the details here: https://github.com/msysgit/git/pull/110

You can circumvent this by using another Git client on Windows or set core.longpaths to true as explained in other answers.

git config --system core.longpaths true

Git is build as a combination of scripts and compiled code. With the above change some of the scripts might fail. That's the reason for core.longpaths not to be enabled by default.

The windows documentation at https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd#enable-long-paths-in-windows-10-version-1607-and-later has some more information:

Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior.

A registry key allows you to enable or disable the new long path behavior. To enable long path behavior set the registry key at HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled (Type: REG_DWORD)

edited Aug 03 '22 at 06:05

Grim

1,938
10
56
123

answered Mar 22 '14 at 09:24

iveqy

19,951
1
15
20

As I understand this incorporated pull request (https://github.com/msysgit/git/pull/122) it should be fixed now. – Papa Mufflon Mar 22 '14 at 09:32
Well yes and no. Read the part in config.txt here: https://github.com/msysgit/git/pull/122/files My advice, don't enable this. Your problem with git status could be one of the "few quirks" warned about. – iveqy Mar 22 '14 at 11:51
58

The limitation to 260 chars in a path is not specific to MSYS, it's a general Windows API imitation. This can be worked around by using Unicode paths, but that has other drawbacks, which is why `core.longpaths` is not enabled by default. Also note that Git for Windows it not compiled against MSYS. Instead, it's a native Windows application that comes with a stripped-down MSYS environment. – sschuberth Feb 14 '15 at 11:03
11

@sschuberth: Are there any drawbacks other than lack of compatibility with programs that do not support long paths? – JAB Sep 06 '15 at 20:14
8

@JAB Another drawback is that long paths always have to be absolute; relative paths are not supported. For further details please see [here](https://msdn.microsoft.com/en-us/library/aa365247.aspx#maxpath). – sschuberth Sep 06 '15 at 20:38
6

Or as a quick fix, just try checkout your repo to C:/ on windows thus reducing number of folder path characters. – Akshay Lokur Nov 16 '16 at 03:49
9

As of Windows 10, you can edit your registry (or apply a group policy) to remove the Windows API filename length restriction. https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/ – jameslafferty Aug 30 '18 at 18:27
1

Thank you really much! changing register and git config finally worked! – Roberto Bisello Oct 18 '18 at 10:42
1

this doesn't work for me, it keeps saying "error: could not lock config file C:/Program Files/Git/mingw64/etc/gitconfig: Permission denied" – Patlatus Nov 01 '18 at 12:43
@Patlatus I think you need to run it as administrator – Raj Sappidi Dec 14 '18 at 17:24
@iveqy Thanks a lot for this NOTE: use this with cmd (Run as Admin) to avoid other errors – Omkar Dixit Aug 12 '19 at 17:44
1

locally '--system' threw a permissions issue (error: could not lock config file C:/Program Files/Git/mingw64/etc/gitconfig: Permission denied) so running without '--system' parameter had the desired effect, thanks :) – alv Oct 02 '19 at 09:32
Note that if you do not have full admin on your machine you can not edit the global gitconfig with git config --system core.longpaths true so instead edit your personal .gitconfig and add in [core] longpaths = true (Can't get this to format???) – Richard Keene Feb 05 '20 at 16:09
2

This worked for me git config --system core.longpaths true But remember to open your terminal as administrator, othercase you will receive a Permission denied error message – Julitillo Apr 01 '20 at 10:18
What if it happens in Linux? Funny as the same works on Windows out of the box. – Royi Apr 12 '20 at 13:43
@ sschuberth Did you mean UNC paths? Unicode paths is slightly a different thing. With the UNC paths (ex: `\\?\c:\path-longer-than-260`) it does work in Windows 7. – Andry May 25 '20 at 06:24
12

Solved for me, but I used `--global` instead of `--system` to avoid the need for admin priviliges. – André Willik Valenti Jul 22 '20 at 20:55
Don't forget to run powershell as admin – Gor Apr 24 '22 at 08:11
@jameslafferty Do I still need to run the `git config` command when I change the registry? And/or vice versa? That's what I don't get. I've changed the registry, but I'm still getting the error. So I'm assuming I need to do both? Cheers – Damian Birchler Nov 30 '22 at 12:39
This command `git config --system core.longpaths true` worked perfectly. For running this command need to open `git cmd` as an `administration` access and run in `Windows 10`. Thanks for help @iveqy – heySushil Jan 09 '23 at 07:03
1

In case someone had a similar situation like me - I was using github desktop when I ran across this (or something like this anyway). Using the command 'git config --system core.longpaths true' resulted in getting a different error. The "trick" was to use a console, not gui. Hope this helps someone – Filip Tvrdoň Mar 07 '23 at 07:48
git config core.longpaths true worked for me :) – Shan Aug 02 '23 at 10:44

score 1234 · Answer 2 · edited Nov 05 '18 at 21:25

1234

You should be able to run the command

git config --system core.longpaths true

or add it to one of your Git configuration files manually to turn this functionality on, once you are on a supported version of Git. It looks like maybe 1.9.0 and after.

edited Nov 05 '18 at 21:25

Peter Mortensen

30,738
21
105
131

answered Sep 30 '14 at 00:51

sparkym3

12,467
2
12
3

14

This config option fixed the issue for me, even with msys as mentioned in the accepted answer. (Specifically, version 1.9.4.msysgit.2). – Alex Osborn Dec 15 '14 at 21:15
6

Sourcetree acts a bit weird unless you "also make sure that SourceTree is using the System’s Git and not the embedded one." - Thanks to [Matej Drolc](http://pingec.si/blog/articles/msysgit-longpath/) for that advice – bstoney Jan 09 '15 at 01:16
51

[Here](https://github.com/msysgit/msysgit/wiki/Git-cannot-create-a-file-or-directory-with-a-long-path) is some background information why this is not enabled by default, and some technical details. – sschuberth Feb 14 '15 at 11:06
@mcsullivan-dander: in my question, I mentioned that I already did `core.longpath true`. At that time, it did not run out of the box. So I think the accepted answer is right for the context. – Papa Mufflon Jun 30 '16 at 07:30
15

get "could not lock config file C:\Program Files\Git\mingw64/etc/gitconfig" after running command above. But @Yash answer worked for me – divideByZero Oct 07 '16 at 09:15
17

@divideByZero running git bash as administrator prevents that error. – Niek Oct 18 '16 at 17:34
3

this worked for me in windows: run git bash as admin, git config --system core.longpaths true, git clone https://yourrepo.git – 3z33etm Jan 03 '17 at 15:38
1

I would use `git config --global core.longpaths=true` to enable survival after a git update. – koppor Mar 01 '17 at 11:12
3

Windows 10 update 1607 and later now support a registry key which will [remove the MAX_PATH limit](https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath) across the entire system. The registry key is HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled and it should be a DWORD set to 1. – Mark Waite Jul 22 '17 at 12:32
this doesn't work for me, it keeps saying "error: could not lock config file C:/Program Files/Git/mingw64/etc/gitconfig: Permission denied" – Patlatus Nov 01 '18 at 12:43
I only was able to do so after I installed Git for Windows. Any other Registry modifications did not help – Arthur Jan 17 '19 at 16:17
I started the prompt command as Administrator and the command was successfully executed. – Jordan Ferr Aug 07 '19 at 19:35
Regarding problems with SourceTree, see: https://stackoverflow.com/questions/996479/naming-convention-for-visual-studio-solutions-and-projects/71279688#71279688 – Jeff Maass Feb 26 '22 at 20:22
`could not lock config file c:/Program Files/Git/etc/gitconfig: permission denied` – KansaiRobot May 11 '23 at 08:16

score 358 · Answer 3 · edited Jan 20 '21 at 12:14

358

This might help:

git config core.longpaths true

Basic explanation: This answer suggests not to have such setting applied to the global system (to all projects so avoiding --system or --global tag) configurations. This command only solves the problem by being specific to the current project.

EDIT:

This is an important answer related to the "permission denied" issue for those whom does not granted to change git settings globally.

edited Jan 20 '21 at 12:14

Akif

7,098
7
27
53

answered Mar 05 '16 at 10:38

Sagiruddin Mondal

5,407
2
29
44

20

Folks here have noted that this setting can introduce some unpredictable behavior so it seems that it's preferable to use the above command as a local setting on projects where that require it rather than appending `--system` which will apply it to all projects – Grant Humphries Jun 17 '16 at 19:34
6

hey, that's just a copypasta of the other highly upvoted answer. might at the very least explain why you prefer removing the --system option.. – Félix Adriyel Gagnon-Grenier Oct 29 '16 at 16:23
4

I didn't have elevated rights and thus this was much easier to do inside the git repository than to ask the IT team to run the global command with elevated rights. Thanks Sagiruddin! – Shayan Ahmad Aug 18 '21 at 10:48
Thank you. I got permission denied and your answer solved my issue – María Jaramillo Sojo Nov 11 '22 at 08:47
@GrantHumphries what "unpredictable behavior" are you referring to? I found the --global flag was what worked for me, and I want to know what to look out for. – M H Jun 23 '23 at 01:01

Saikat · Answer 4 · 2021-10-21T14:33:27.163

232

Steps to follow (Windows):

Run Git Bash as administrator (right-clicking the app shortcut will show the option to Run as Administrator )
Run the following command:

git config --system core.longpaths true

Note: if step 2 does not work or gives any error, you can also try running this command:

git config --global core.longpaths true

Read more about git config here.

edited Oct 21 '21 at 14:33

answered Mar 03 '18 at 04:50

Saikat

14,222
20
104
125

2

Thanks for the answer! Using --global command solved the issue for me! – Sankalpa Wijewickrama Apr 05 '23 at 10:53
Thanks a lot. The second command actually helped me out; Because it was throwing an error by saying "Permission denied". – Matin May 01 '23 at 21:18

score 126 · Answer 5 · edited Nov 05 '18 at 21:27

126

Create .gitconfig and add

[core]
longpaths = true

You can create the file in a project location (not sure) and also in the global location. In my case the location is C:\Users\{name}\.

edited Nov 05 '18 at 21:27

Peter Mortensen

30,738
21
105
131

answered Apr 16 '16 at 11:55

Yash

6,644
4
36
26

15

You can also do this with the following command: `git config --global core.longpaths true` – SoftWyer Nov 09 '16 at 13:05
git config --global core.longpaths true worked for me thanks – Rama Krshna Ila Sep 29 '17 at 22:13
2

Using Visual Studio the git bash solutions above did not work for me, but finding the .git/config file for the project and editing as shown above did. Thanks yash. – andrew pate May 02 '18 at 13:23
this worked for me, i located that file and modified it manually – Patlatus Nov 01 '18 at 12:44
1

The above mentioned and verified answers are correct but with the permissions which is granted to the file, it might not be possible to update the file with those commands. This approach is really easy because this is the manual approach and it worked for me really well. You can easily find the `.gitconfig` file in the following path `C:\Users\{username}` and simply edit it. – Kavindu N Jul 30 '19 at 04:19
this one is the convenient solution than using the command prompt that requires me permissions – aj go May 02 '20 at 05:46
In my case, the config file already existed and I found it here: `C:\Program Files\Git\etc\gitconfig`. – Jaime Montoya May 26 '21 at 14:23

score 58 · Answer 6 · answered Dec 01 '16 at 11:26

To be entirely sure that it takes effect immediately after the repository is initialized, but before the remote history is fetched or any files checked out, it is safer to use it this way:

git clone -c core.longpaths=true <repo-url>

-c key=value

Set a configuration variable in the newly-created repository; this takes effect immediately after the repository is initialized, but before the remote history is fetched or any files checked out. The key is in the same format as expected by git-config1 (e.g., core.eol=true). If multiple values are given for the same key, each value will be written to the config file. This makes it safe, for example, to add additional fetch refspecs to the origin remote.

More info

score 39 · Answer 7 · edited Nov 05 '18 at 21:31

39

The better solution is enable the longpath parameter from Git.

git config --system core.longpaths true

But a workaround that works is remove the node_modules folder from Git:

$ git rm -r --cached node_modules
$ vi .gitignore

Add node_modules in a new row inside the .gitignore file. After doing this, push your modifications:

$ git add .gitignore
$ git commit -m "node_modules removed"
$ git push

edited Nov 05 '18 at 21:31

Peter Mortensen

30,738
21
105
131

answered Aug 22 '16 at 18:44

Janderson Silva

1,787
17
14

3

There's a good reason to keep the node_modules folder checked into git: If you want your software to behave the same after a year of modules potentially vanishing from npm. – cfstras Aug 24 '16 at 15:00
@cfstras if some library has a vulnerabily and you don't update periodically, certainly you'll have security problems. – Janderson Silva Aug 26 '16 at 12:31
1

Of course you have to upgrade your dependencies. But only when _you_ want to, and if something were to break, you would want your backup in git... – cfstras Aug 26 '16 at 14:47
Is true. I'll edit my anwser. Thank you for you comment. – Janderson Silva Aug 26 '16 at 16:40
6

No need to commit `node_modules`: the `packages.lock`file is here to ensure the version installed by `npm install`will always be the same, until you make a `npm update` – Pierre-Olivier Vares Oct 17 '19 at 14:28

score 39 · Answer 8 · answered Nov 22 '21 at 06:09

39

This worked for me

Run as terminal as administrator. And run the command below.

git config --system core.longpaths true

answered Nov 22 '21 at 06:09

A v o c a d o

526
4
3

score 34 · Answer 9 · answered Dec 20 '18 at 09:04

34

Executing git config --system core.longpaths true thrown an error to me:

"error: could not lock config file C:\Program Files (x86)\Git\mingw32/etc/gitconfig: Permission denied"

Fixed with executing the command at the global level:

git config --global core.longpaths true

answered Dec 20 '18 at 09:04

Arpit Aggarwal

27,626
16
90
108

The global settings affect only the current user, whereas system settings affect all the users on the machine. If this is your workstation they're effectively the same as you may use only one user. – towel Jan 15 '19 at 17:14
5

If you're command line application Ran as Administrator, first command would work! – Sachith Dickwella Mar 07 '19 at 05:13

score 21 · Answer 10 · answered Apr 07 '22 at 03:08

Download & Install Git bash from here: https://git-scm.com/download/win
Run the git bash gui as administrator and run this command: git config --system core.longpaths true
Now clone any repository.
If the problem is not fixed try this command: git config --global core.longpaths true
If it does not help try restarting the windows.

score 18 · Answer 11 · edited Nov 05 '18 at 21:35

18

You could also try to enable long file paths.

If you run Windows 10 Home Edition you could change your Registry to enable long paths.

Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem in regedit and then set LongPathsEnabled to 1.

If you have Windows 10 Pro or Enterprise you could also use Local Group Policies.

Go to Computer Configuration → Administrative Templates → System → Filesystem in gpedit.msc, open Enable Win32 long paths and set it to Enabled.

edited Nov 05 '18 at 21:35

Peter Mortensen

30,738
21
105
131

answered Sep 03 '18 at 10:36

Julian Veerkamp

1,694
2
16
20

8

I believe this must be done in combination with the git config, and it's worth noting it doesn't work with Windows Explorer for the reasons mentioned [here](https://superuser.com/a/1114683/103148). – Neo Sep 04 '18 at 10:31
Win32 - I wonder if this can help if the application is 64bit? – Henning Larsen Feb 18 '22 at 20:32

score 18 · Answer 12 · answered Nov 26 '19 at 14:18

18

git config --global core.longpaths true

The above command worked for me. Using '--system' gave me config file not locked error

answered Nov 26 '19 at 14:18

amalik2205

3,962
1
15
21

3

for Github Desktop users, this is the only one that works because Github Desktop uses its own Git config. – Csa77 Nov 30 '19 at 10:38

score 12 · Answer 13 · answered Dec 04 '20 at 20:03

TortoiseGit (Windows)

For anyone using TortoiseGit for Windows, I did this:

(1) Right-click on the folder containing your project. Select TortoiseGit -> Settings.

(2) On the "Git" tab, click the button to "Edit local .git/config".

(3) In the text file that pops up, under the [core] section, add: longpaths = true

Save and close everything, then re-try your commit. For me, this worked.

I hope this minimizes any possible system-wide issues, since we are not editing the global .gitconfig file, but rather just the one for this particular repository.

Niroshan Ratnayake · Answer 14 · 2020-11-28T05:27:59.803

8

In Windows, you can follow these steps which worked for me.

Open your cmd or git bash as an administrator

Give the following command either from cmd or git bash which you ran above as an administrator

git config --system core.longpaths true

This will allow accessing long paths globally
And now you can clone the repository with no issues with long paths

edited Nov 28 '20 at 05:27

answered Nov 28 '20 at 05:18

Niroshan Ratnayake

3,433
3
20
18

score 7 · Answer 15 · edited Nov 05 '18 at 21:32

7

Move repository to root of your drive (temporary fix)

You can try to temporarily move the local repository (the entire folder) to the root of your drive or as close to the root as possible.

Since the path is smaller at the root of the drive, it sometimes fixes the issues.

On Windows, I'd move this to C:\ or another drive's root.

edited Nov 05 '18 at 21:32

Peter Mortensen

30,738
21
105
131

answered Jul 27 '17 at 12:35

Dheeraj Bhaskar

18,633
9
63
66

2

This is the only thing that solved my issue. It was that I had too many folders in the path. – J Brun Apr 26 '18 at 20:26

score 3 · Answer 16 · answered May 06 '20 at 04:56

3

In a windows Machine

Run Command Prompt as administrator then run below command

git config --system core.longpaths true

answered May 06 '20 at 04:56

kartick shaw

915
13
5

score 2 · Answer 17 · edited Nov 05 '18 at 21:26

2

I had this error too, but in my case the cause was using an outdated version of npm, v1.4.28.

Updating to npm v3 followed by

rm -rf node_modules
npm -i

worked for me. npm issue 2697 has details of the "maximally flat" folder structure included in npm v3 (released 2015-06-25).

edited Nov 05 '18 at 21:26

Peter Mortensen

30,738
21
105
131

answered Nov 02 '15 at 12:25

James Green

1,827
1
13
13

score 1 · Answer 18 · edited Nov 05 '18 at 21:32

1

If you are working with your encrypted partition, consider moving the folder to an unencrypted partition, for example a /tmp, running git pull, and then moving back.

edited Nov 05 '18 at 21:32

Peter Mortensen

30,738
21
105
131

answered Feb 20 '18 at 22:51

augustowebd

382
2
8

Filename too long in Git for Windows

18 Answers18

Steps to follow (Windows):

TortoiseGit (Windows)

Move repository to root of your drive (temporary fix)

In a windows Machine

Linked

Related