I am getting the below error while pulling changes from a GIT branch
….
cannot stat ‘somelongfilename.sql’: Filename too long
c
As a solution, I am trying to add longpaths = true
to gitconfig file. This is located in the system default folder and I do not have permission to edit this file.
I am looking for a quick solution here. Is there any other way I can resolve this issue instead of editing gitconfig file?
asked Dec 12, 2022 at 10:25
3
git
takes the -c
option to set a configuration option for the command. For example git -c core.longpaths=true pull ...
should enable core.longpaths=true
for the duration of the pull
command.
Note, however, that you still need to set the system-level requirements to enable long paths on Windows before git
can take advantage of them.
answered Dec 12, 2022 at 11:42
Edward ThomsonEdward Thomson
72.5k14 gold badges156 silver badges183 bronze badges
I solved the issue with the below command
Used
git config --global core.longpaths true
instead of
git config --system core.longpaths true
Stefan
1,53113 silver badges29 bronze badges
answered Dec 12, 2022 at 13:02
Soft_API_DevSoft_API_Dev
1331 gold badge1 silver badge8 bronze badges
In this article, we would like to show how to let git working with long paths.
Quick solution (run it as administrator):
git config --system core.longpaths true
Below you can find the example, when the problem occurred and different ways to set up loner paths for git using different approaches.
1. Problem description
When I execute git pull
command I get fllowing error:
$ git pull
error: cannot stat 'very/long/path/here.../filename.png': Filename too long
Aborting
Updating 42f6e00..66294e7
2. Problem solution
There are two ways how to fix configuration:
- with
git
command, - with
.gitignore
file.
2.1. with git
command example
When we want to set up paths we can execute in console following command:
- for entire operating system:
git config --system core.longpaths true
- or only for the current repository:
git config core.longpaths true
2.2. with .gitconfig
file example
The solution presented in this section works only with repositories that use the file.
Solution:
- go to
.gitconfig
file (example path for a user in Linux~/.gitconfig
), - create
[core]
section if it does not exist, - add
longpaths = true
in the section.
.gitconfig
file example:
[core]
longpaths = true
Note:
.gitcofig
file can be located inside project location or in the user home directory.
When checking out a68958d of IdentityServer4.Samples, the following error is got:
Updating dcbcc10..a68958d
error: cannot stat ‘Quickstarts/Combined_AspNetIdentity_and_EntityFrameworkStorage/src/IdentityServerWithAspIdAndEF/Data/Migrations/IdentityServer/PersistedGrantDb/20180109200712_InitialIdentityServerPersistedGrantDbMigration.Designer.cs’: Filename too long
OS: Windows 10
Git client: Atlassian SourceTree
Change the path to be somewhere shorter on your host OS.
Also, this seems to be a general question about IdentityServer — not a bug report or an issue.
Please use one of the our free or commercial support options
See here for more details.
Thanks!
@Nuschler , Your solution has resolved the issue! Thanks.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
lock
bot
locked as resolved and limited conversation to collaborators
Jan 13, 2020
Learn how to solve «commit failed, filename too long» error on git Windows.
Problem
Windows does not properly support files and directories longer than 260 characters. This applies to Windows Explorer, cmd.exe,GitHub for windows and many other applications (including many IDEs as well as bash, perl and tcl that come with Git for Windows). For that reason, the long paths support in Git for Windows is disabled by default. You can read more about the 260 characters limit in windows here.
If you open the log, an error with the following description should be listed :
14:02:42.8556|WARN|thread: 1|StandardUserErrors|Showing user error Failed to create a new commit.
GitHub.IO.ProcessException: fatal: unable to stat 'plugins/toolongname/example/app/platforms/toolongname/toolongname/build/intermediates/classes/debug/org/toolongname/toolongname/toolongname$toolongname$toolongname.class': Filename too long
As you can see, indeed the filename (or path) has more than 260 characters, Git has a limit of 4096 characters for a filename, but on windows when the git client is compiled with msys (for example the official GitHub application for windows), it uses an older version of the windows api and there’s a limit of 260 characters for a filepath.
Solution
Open the Github Powershell or cmd.exe (you need to have git as an environment variable) and execute the following command :
git config --system core.longpaths true
As we are changing the configuration of git, you can execute it directly in your project or from any path if the Git variable is available.
The change should be executed immediately and you can procceed with the commits from the command line or even with the GitHub application, have fun !
A quick guide on how to fix the git clone error file error Filename too long git in windows machines. The fix is run «git config —system core.longpaths true» as admin.
1. Introduction
In this tutorial, We’ll learn how to fix the git clone error «Filename too long» in windows operating systems Powershell and GitHub Application. This happens when doing a git clone from remote repositories.
Most used Git Commands
This error does not come for the UNIX or mac users. So they can push the long length file names to git but the issues occur only for the windows users. Because this capability is disabled by default in the Windows operating system.
Usually, 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.
2. Filename too long — Solution 1 — Git Global Level
Follow the steps below to fix «Filename is too long» in git.
- Update the git version to the latest from here. If you have updated, ignore this step.
- Navigate to your project folder
- Open the Git Bash and run as administrator
- To enable the long paths to run «git config core.longpaths true» in git bash
Now clone the project that has long file names that should not produce such error now.
This is a solution that works for all the times and no one reported after applying this solution. This works for all the repositories which will be clone in future projects.
3. Filename too long — Solution 2 — Git specific project
If you have clone already project into local machine and while getting new changes using the «git pull» command, it will produce the git filenames are too long error.
To apply the fix only to this project, just go to the project home directory and find the «.git» folder.
Open the config file and look at the [core] section. At the end of this section add longpaths to true as «longpaths = true«.
[core] repositoryformatversion = 0 filemode = false bare = false logallrefupdates = true symlinks = false ignorecase = true longpaths = true
This fix works only for this repo.
4. Git Filename too long — Solution 3 — Through Git Clone Command
If you want to fix this while cloning the repository, there is an option to do as part of the «git clone» command. First to enable flags to accept with the option «-c» and next pass core.longpaths=true as below.
git clone -c core.longpaths=true
5. Conclusion
In this article, We’ve seen how to fix the common git error ‘git filename too long’ which comes into existence working with windows. Shown 3 ways to fix this error.
References:
Stackoverflow 1
Stackoverflow 2
Хотя я демонстрирую ошибку на примере работы с системами контроля версий для MacOsX и Windows — это проблема более глобальная и поймать её вы можете в любой другой комбинации софта (да хоть в той же Samba).
Используемый подход решения проблемы наверняка не единственный, но, при этом, довольно универсален.
Различные файловые системы по разному хранят информацию об имени файла.
Из-за чего возникают коллизии если разработка ведётся многими людьми и у всех разные ОС.
В моём случае получилось так, что другой разработчик закоммитил в репозиторий файл длиной 180 русских букв.
$ echo "яяяяяяяяя яя яяяя яя яяяяяяяяяя яяяяяяяяя я яяяяяя я яяя яяяяяяяяя яяяяяяяяяяяяя яяяяяяяя я яяяяяяяяяяяяяяяяяя яяяяяя яя яяяяяя яяяяяяяяяяяяя яяяяяяяя яяяяя яяяяяя я яяя яяяяя яяя" | wc -m 180
Но
$ echo "яяяяяяяяя яя яяяя яя яяяяяяяяяя яяяяяяяяя я яяяяяя я яяя яяяяяяяяя яяяяяяяяяяяяя яяяяяяяя я яяяяяяяяяяяяяяяяяя яяяяяя яя яяяяяя яяяяяяяяяяяяя яяяяяяяя яяяяя яяяяяя я яяя яяяяя яяя" | wc -c 334
Русские буквы занимают два байта вместо одного.
При попытке создать такой файл под MacOsX на диске со стандартной файловой системой HFS+
$ touch "яяяяяяяяя яя яяяя яя яяяяяяяяяя яяяяяяяяя я яяяяяя я яяя яяяяяяяяя яяяяяяяяяяяяя яяяяяяяя я яяяяяяяяяяяяяяяяяя яяяяяя яя яяяяяя яяяяяяяяяяяяя яяяяяяяя яяяяя яяяяяя я яяя яяяяя яяя"
Получим странное
$ ls я* яяяяяяяяя яя яяяя яя яяяяяяяяяя яяяяяяяяя я яяяяяя я яяя яяяяяяяяя яяяяяяяяяяяяя яяяяяяяя я яяяяяяяяяяяяяяяяяя яяяяяя яя яяяяяя яяяя#299CD031
Несмотря на заявляемые 255 знаков в кодировке UTF-16 (точно также в NTFS).
А если такой файл попробовать отредактировать, например с помощью vim, то после сохранения и выхода
:wq
файл исчезает.
Кстати, несмотря на то, что некоторые ФС поддерживают ещё более длинные имена, штатные утилиты linux, по всей вероятности, всё равно оперируют байтами и поэтому комманда touch мне стабильно выдавала ошибку: “File name too long”
Я, например, пробовал ReiserfFS под Ubuntu 12.04 LTS.
Возвращаясь к MacOs. Именно эту ошибку я поймал при попытке получить последние изменения из репозитория.
$ git svn rebase First, rewinding head to replay your work on top of it... error: cannot stat '$73_chars_4_deep_levels_path_with_spaces/$180_chars_file_name_with_spaces_too': File name too long error: cannot stat '$73_chars_4_deep_levels_path_with_spaces/$180_chars_file_name_with_spaces_too': File name too long error: cannot stat '$73_chars_4_deep_levels_path_with_spaces/$180_chars_file_name_with_spaces_too': File name too long could not detach HEAD rebase refs/remotes/git-svn: command returned error: 1
Первой моей идеей стало установить Windows внутри VirtualBox и там настроить Cygwin, т.к. в этой экосистеме файлы с длинными именами чувствуют себя вольготно.
Но, всё-таки, ОС внутри виртуальной машины — это довольно тяжелая штука в плане потребления ресурсов.
К тому же, Cygwin/MSysGit имеют и другие проблемы, с которыми приходится периодически бороться.
И, вот, после неудачи с Windows и Ubuntu, ко мне пришла идея попробовать создать образ диска с подходящей ФС средствами MacOS.
Хотя Linux и позволяет создавать и монтировать образы дисков даже более гибко, но надо что-то в нём докручивать, либо чтобы ядро поддерживало длинные уникодные имена, либо выставлять однобайтную локаль и на лету конвертировать файлы с помощью чего-то вроде iconv или средствами самого гита.
В комплекте с макосью идёт инструмент DiskUtility.
Где я для начала попробовал создать DMG-образы с NTFS.
Но, вероятно, имеющиеся у меня драйверы NTFS-3G и Tuxero, содержат ошибку.
В обоих случаях я получал до боли знакомый “File name too long”.
Удача меня ждала с ФС ExFat.
$ touch "яяяяяяяяя яя яяяя яя яяяяяяяяяя яяяяяяяяя я яяяяяя я яяя яяяяяяяяя яяяяяяяяяяяяя яяяяяяяя я яяяяяяяяяяяяяяяяяя яяяяяя яя яяяяяя яяяяяяяяяяяяя яяяяяяяя яяяяя яяяяяя я яяя яяяяя яяя"
И, ву-а-ля
$ ls я* яяяяяяяяя яя яяяя яя яяяяяяяяяя яяяяяяяяя я яяяяяя я яяя яяяяяяяяя яяяяяяяяяяяяя яяяяяяяя я яяяяяяяяяяяяяяяяяя яяяяяя яя яяяяяя яяяяяяяяяяяяя яяяяяяяя яяяяя яяяяяя я яяя яяяяя яяя
После перемещения своего проекта в новый раздел, вся остальная операция прошла как по-маслу.
Далее, можно почитать про Unicode в названиях файлов в HFS.
When Bamboo checks out changes from repositories using the Windows Git.exe executable, the task fails and the following appears in the job log
java.lang.RuntimeException : com.atlassian.bamboo.plugins.stash.repository.StashRepositoryException: com.atlassian.bamboo.repository.RepositoryException: Checkout to revision <hash> has failed.command 'C:Program FilesGitcmdgit.exe' checkout -f master failed with code 1. Working directory was [<job working directory>].,
stderr: error: unable to create file <filename>: Filename too long error: unable to create file
According to the msysgit wiki on GitHub and the related fix this error, Filename too long, comes from a Windows API limitation of file paths having 260 characters or fewer.
To resolve this issue, we could change the Windows default 260 character limit in the Windows registry or by configuring the core.longpaths workaround in git config.
The solution applies to the Windows system that runs the build and not necessarily only to the Bamboo Server. If you have Bamboo Remote or Elastic Agents running on Windows, please be mindful that the steps below need to be followed on every agent that could possibly run such builds
Starting in Windows 10 (Windows Server 2016), version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behaviour. We need to set the Windows default 260 character limit by updating the registry as mentioned here.
Go to the registry key ComputerHKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystemLongPathsEnabled
(Type: REG_DWORD) must exist and be set to 1.
New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlFileSystem" `
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
The git configuration setting can be used for Windows versions lower than 2016 and Windows 10.
This setting is disabled by default by git to prevent users from checking out files that Windows Explorer, cmd/bash or some IDE cannot handle.
For Git configuration run the following command from GitBash or the Git CMD prompt:
git config --system core.longpaths true
This will allow file paths of 4096 characters.
Some users have reported the —system parameter does not work, but the —global one does, which would change the command to:
git config --global core.longpaths true
1. Purpose
In this post, I would demonstrate how to solve the following error when using git clone
in windows:
2. The reason and solution
2.1 The reason of this problem
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 it’s a limitation of msys and not of Git. You can read the details here: https://github.com/msysgit/git/pull/110.
The root cause of the technical limitation of 260 chars lies within the Windows API. Microsoft’s online article Naming Files, Paths, and Namespaces describes the reasons. Because Git was originally written on Linux, there’s no such limitation. Thus the problem occurs when the original Git code is compiled on the Windows platform.
2.2 The solutions
2.2.1 Solution #1
You can solve this problem by using another Git client on Windows or set core.longpaths
to true
as explained in other answers.
Run the following command (Run as terminal as administrator):
git config --system core.longpaths true
If you encounter this error:
"error: could not lock config file C:Program Files (x86)Gitmingw32/etc/gitconfig: Permission denied"
You can fix the problem by running this:
git config --global core.longpaths true
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.
2.2.2 Solution #2
you can Create .gitconfig
and add this:
You can create above file in a project location and also in the global location. In my case the location is C:Users{name}
.
2.2.3 Solution #3
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.
2.2.4 Solution #4
You could also try to enable long file paths in windows.
If you run Windows 10 Home Edition you could change your Registry to enable long paths.
Go to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystem
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.
2.3 The future
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 HKLMSYSTEMCurrentControlSetControlFileSystem LongPathsEnabled (Type: REG_DWORD)
3. Summary
In this post, I demonstrated how to solve the Filename too long
problem when using git clone
commands, the key point is to understand why the error happens, you can workaround this by using git commands or just alter windows settings to avoid this problem. That’s it, thanks for your reading.