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?
asked Mar 22, 2014 at 9:14
Papa MufflonPapa Mufflon
16.4k5 gold badges27 silver badges35 bronze badges
6
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
HKLMSYSTEMCurrentControlSetControlFileSystemLongPathsEnabled
(Type: REG_DWORD)
Grim
3,0659 gold badges55 silver badges117 bronze badges
answered Mar 22, 2014 at 9:24
20
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.
answered Sep 30, 2014 at 0:51
sparkym3sparkym3
12.2k2 gold badges11 silver badges3 bronze badges
13
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.
Akif
6,7057 gold badges24 silver badges51 bronze badges
answered Mar 5, 2016 at 10:38
4
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.
answered Mar 3, 2018 at 4:50
SaikatSaikat
13k18 gold badges102 silver badges119 bronze badges
1
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}.
answered Apr 16, 2016 at 11:55
YashYash
6,3544 gold badges35 silver badges26 bronze badges
7
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
answered Dec 1, 2016 at 11:26
WatchmakerWatchmaker
4,6681 gold badge34 silver badges38 bronze badges
0
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
answered Aug 22, 2016 at 18:44
5
This worked for me
Run as terminal as administrator. And run the command below.
git config --system core.longpaths true
answered Nov 22, 2021 at 6:09
Executing git config --system core.longpaths true thrown an error to me:
«error: could not lock config file C:Program Files
(x86)Gitmingw32/etc/gitconfig: Permission denied»
Fixed with executing the command at the global level:
git config --global core.longpaths true
answered Dec 20, 2018 at 9:04
Arpit AggarwalArpit Aggarwal
26.6k15 gold badges86 silver badges106 bronze badges
2
- 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.
answered Apr 7, 2022 at 3:08
git config --global core.longpaths true
The above command worked for me. Using ‘—system’ gave me config file not locked error
answered Nov 26, 2019 at 14:18
amalik2205amalik2205
3,8061 gold badge13 silver badges20 bronze badges
1
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_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.
answered Sep 3, 2018 at 10:36
Julian VeerkampJulian Veerkamp
1,6142 gold badges17 silver badges20 bronze badges
2
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.
answered Dec 4, 2020 at 20:03
RichardRichard
1,82220 silver badges27 bronze badges
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
answered Nov 28, 2020 at 5:18
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.
answered Jul 27, 2017 at 12:35
Dheeraj BhaskarDheeraj Bhaskar
18.4k9 gold badges63 silver badges66 bronze badges
1
In a windows Machine
Run Command Prompt as administrator then run below command
git config —system core.longpaths true
answered May 6, 2020 at 4:56
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).
answered Nov 2, 2015 at 12:25
James GreenJames Green
1,8171 gold badge14 silver badges13 bronze badges
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.
answered Feb 20, 2018 at 22:51
augustowebdaugustowebd
3822 silver badges8 bronze badges
0
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 fileAccording 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 -ForceThe 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 trueThis 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 trueA 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.
![3 Ways to Fix git "Filename too long" Error in Windows [Fixed]](https://1.bp.blogspot.com/-wA4UaZSbgxk/XorggdWB4-I/AAAAAAAACck/ok9lrgMH5DsH3HL1pskkEmHymr0pM3ORgCLcBGAsYHQ/s640/3%2BWays%2Bto%2BFix%2Bgit%2B%2522Filename%2Btoo%2Blong%2522%2BError%2Bin%2BWindows%2B%255BFixed%255D.png "3 Ways to Fix git \"Filename too long\" Error in Windows [Fixed]")
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
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.
Содержание
- Filename too long on clone on Windows 10 #8023
- Comments
- luveti commented Jul 25, 2019 •
- Description
- Version
- Steps to Reproduce
- Expected Behavior
- Actual Behavior
- Additional Information
- shiftkey commented Jul 25, 2019
- luveti commented Jul 25, 2019
- shiftkey commented Jul 25, 2019
- sarang13579 commented Dec 9, 2019
- Bamboo Support
- Knowledge base
- Products
- Jira Software
- Jira Service Management
- Jira Core
- Confluence
- Bitbucket
- Resources
- Documentation
- Community
- Suggestions and bugs
- Marketplace
- Billing and licensing
- Viewport
- Confluence
- Git checkouts fail on Windows with «Filename too long error: unable to create file» errors
- Related content
- Still need help?
- Problem
- Cause
- Resolution
- Filename too long in Git for Windows
- 16 Answers 16
- Слишком длинное имя файла в git для windows
- 11 ответов
- Действия:
- переместить РЕПО в корень вашего диска (временное исправление)
- Of Too Long File Names (in Windows) and Git
- 8.3 Filenames and Other Old Things
- MAX_PATH
- core.longpaths
Filename too long on clone on Windows 10 #8023
Description
Unable to clone repo with long file paths
Version
Steps to Reproduce
Expected Behavior
It should properly handle long file paths on Windows
Actual Behavior
It doesn’t handle long file paths ☹
Additional Information
I would copy and paste the path here but it looks like text selection is disabled in that dialog.
Here’s a screenshot instead: 
The text was updated successfully, but these errors were encountered:
@luveti thanks for the report!
Because of a Windows API limit paths longer than MAX_PATH (260 characters) on Windows are not supported by default in Git for Windows, which is used in Desktop. This document talks about the limitation and the workaround (using the extended-length path syntax).
Have you set core.longpaths to true before cloning to opt-in for using the extended-length path support?
There’s some caveats to this from the Git for Windows documentation which is why we don’t enable this by default:
I know you guys are trying to keep the interface simple for beginners, but it would be awesome if you had another section or tab for setting config values!
I’m glad you were able to work around it.
I know you guys are trying to keep the interface simple for beginners, but it would be awesome if you had another section or tab for setting config values!
Because of a Windows API limit paths longer than MAX_PATH (260 characters) on Windows are not supported by default in Git for Windows, which is used in Desktop. This document talks about the limitation and the workaround (using the extended-length path syntax).
Have you set core.longpaths to true before cloning to opt-in for using the extended-length path support?
There’s some caveats to this from the Git for Windows documentation which is why we don’t enable this by default:
Because of a Windows API limit paths longer than MAX_PATH (260 characters) on Windows are not supported by default in Git for Windows, which is used in Desktop. This document talks about the limitation and the workaround (using the extended-length path syntax).
Have you set core.longpaths to true before cloning to opt-in for using the extended-length path support?
There’s some caveats to this from the Git for Windows documentation which is why we don’t enable this by default:
Thank you very much, it worked. You have relieved me of a great headache
Источник
Bamboo Support
Knowledge base
Products
Jira Software
Project and issue tracking
Jira Service Management
Service management and customer support
Jira Core
Manage any business project
Confluence
Bitbucket
Git code management
Resources
Documentation
Usage and admin help
Answers, support, and inspiration
Suggestions and bugs
Feature suggestions and bug reports
Marketplace
Billing and licensing
Frequently asked questions
Viewport
Confluence
Git checkouts fail on Windows with «Filename too long error: unable to create file» errors
Related content
Still need help?
The Atlassian Community is here for you.
Problem
When Bamboo checks out changes from repositories using the Windows Git.exe executable, the task fails and the following appears in the job log
Cause
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.
Resolution
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.
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.
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:
This will allow file paths of 4096 characters.
Источник
Filename too long in Git for Windows
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.
What am I missing here?
16 Answers 16
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 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.
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)
Источник
Слишком длинное имя файла в git для windows
Я использую Git-1.9.0-preview20140217 для Windows. Как я знаю, этот выпуск должен исправить проблему с слишком длинными именами файлов. Но не для меня.
11 ответов
git имеет ограничение в 4096 символов для имени файла, за исключением windows, когда git скомпилирован с msys. Он использует более старую версию api windows, и есть ограничение в 260 символов для имени файла.
насколько я понимаю, это ограничение msys, а не git. Вы можете прочитать подробности здесь : https://github.com/msysgit/git/pull/110
вы можете обойти это, используя другой Git-клиент в windows или set core.longpaths to true как объяснено в других ответах ниже.
вы должны иметь возможность выполнить команду
или добавьте его в один из ваших файлов конфигурации git вручную, чтобы включить эту функцию, как только вы находитесь в поддерживаемой версии git. Похоже, 1.9.0 и после.
вы можете создать файл в местоположении проекта (не уверен), а также в глобальном местоположении в моем случае местоположение c:Users
лучшее решение-включить параметр longpath из git.
чтобы быть полностью уверенным, что он вступает в силу сразу после инициализации репозитория, но до извлечения удаленной истории или извлечения файлов, безопаснее использовать его следующим образом:
задайте переменную конфигурации во вновь созданном репозитории; это вступает в силу сразу после инициализации репозитория, но перед извлечением удаленной истории или извлечением файлов. Ключ в том же формат, как и ожидалось git-config1 (напр., ядро.Эол=правда). Если для одного и того же ключа задано несколько значений, то каждое значение будет записано в файл config. Это делает его безопасным для например, чтобы добавить дополнительную выборку refspecs к исходному удаленному.
Действия:
подробнее о git config здесь
переместить РЕПО в корень вашего диска (временное исправление)
вы можете попытаться временно переместить локальное РЕПО (всю папку) в корень вашего диска или как можно ближе к корню.
поскольку путь меньше в корне диска, он иногда устраняет проблемы.
на windows, я бы переместил это в C: или корень другого диска
вы также можете попробовать включить длинные пути к файлам
если вы запустите Windows 10 Home Edition, вы можете изменить реестр, чтобы включить длинные пути.
если у вас есть Windows 10 Pro или Enterprise, вы также можете использовать локальные групповые политики.
У меня тоже была эта ошибка, но в моем случае причиной было использование устаревшей версии npm, v1.4.28.
обновление до npm v3 с последующим
работал для меня. выпуск npm 2697 содержит сведения о» максимально плоской » структуре папок, включенной в npm v3 (выпущен 2015-06-25).
Источник
Of Too Long File Names (in Windows) and Git
I was recently involved in a restructure of git repositories for a moderate sized Java code base. As it’s a Java code base you end up with impossibly long paths due to package structure, e.g.:
In reality, I work with significantly deeper structures (huzzah). I also work on Windows at work. This becomes an issue when I start messing around with git and am greeted by the following:
The TLDR; result of this is that you can make git play nice with long file names on Windows with the following:
Or you can switch operating systems. People will often suggest this in an attempt to rustle my jimmies. I understand as such a handsome, smart, great, good at video games, athletic, and funny dude, it’s essential that my jimmies are regularly tested via a rustling. However, my jimmies remain steadfast, and for the remainder of this post I wish to discuss as to why the above happens, and how it all works under the hood, because it’s interesting, and me an my jimmies have to do something.
8.3 Filenames and Other Old Things
This is interesting because the file systems that Windows uses today aren’t a clean break from those used historically. There are compatibility considerations to be made (such as being able to still work with 8.3 filenames), and there are bits of the operating system that are made up of bits from other, old operating systems.
MAX_PATH
The Windows API has a constant, MAX_PATH, which is defined to be 260. There are various intricacies to how this ends up impacting your paths and file names (see the link). However, the net upshot is that you have a path limit that you can hit with only a moderate amount of effort, as opposed to say 4096, which you really have to make some effort to go for (4096 being a common value for PATH_MAX).
MAX_PATH appears to be one of these historical things. The Windows API enforces this limit for its ANSI file manipulation functions. These functions also have Unicode versions, which have a much greater character limit of 32767 characters.
The file manipulation functions that rely on MAX_PATH being 260 have been around for a long long time, and I imagine the value remains unchanged to avoid a horrifying compatibility nightmare (though the current path limit situation isn’t great either). Just as 8.3 filenames are still with us, so too do historical path limits continue to hang about.
\? is the special prefix used by Windows to designate an extended path. E.g. \?D:BryceIsRad. The \? prefix is used by the OS to signify an extended path, but is not part of the path. The actual wrangling on long paths in done under the hood, and the prefix just means that the OS will be passed to the system with little modification. There are ramifications to this, such as a paths using the \? prefix cannot be relative (all relative paths are limited by MAX_PATH).
This prefix can also be used with the Universal Naming Convention, a Microsoft specification for paths to resources that may be on a network. In such cases the \?UNC prefix is used. E.g. \?UNCBrycesServerBryceIsRad
And with all of this discussed with can move on to how it impacts git on Windows!
core.longpaths
The core.longpaths config option is special to msysgit. If you grep through the git source you won’t find a reference to it. And as a trap for new players, if you do a grep of the source for msysgit without checking out submodules you also won’t find it. But if you grep the source of a msysgit with its submodules inited and updated, then you’re in for a treat.
Msysgit has its own git submodule with modifications. This submodule lives in the git directory which hangs directly off the root of the msysgit directory structure. This is where the adventure starts:
msysgit/git/config.c has the following change:
to handle the longpaths var being set. While you can set the var on a non msys version of git, it won’t do anything, as there’s no code to handle it.
Internally the core_long_paths variable is used to track if long paths are enabled. The variable is declared in msysgit/git/environment.c which is described by a comment as follows:
We put all the git config variables in this same object file, so that programs can link against the config parser without having to link against all the rest of git.
Aside from that, the core_long_paths variable is used in a few other files, importantly msysgit/git/compat/mingw.h and msysgit/git/compat/mingw.c. It’s used by the function xutftowcs_long_path, which is a special long path version of xutftowcs, which in turn is a function that converts UTF-8 names into UTF-16LE. This is because Windows likes its wide chars at 16 bits, and the path should be expressed in wide chars.
Diving further into the code one can find the handle_long_path function, which does kinda what it sounds like. handle_long_path has an arg, expand, which stores the value from core_long_paths, and is used to gate the creation of long paths starting with \?. If the variable is not true, an error will be returned if the path is too long:
and after this code is the juicy bit where long paths are created:
and these are the paths that will be passed to the Windows API by msysgit! Neat.
Источник