Repository navigation
Windows, Pathname too long (>256 chars) #52
Description
Using *current version of msysgit for Windows (Win7 64bit), there is a big issue when
having pathnames longer than 256 characters.
The problem occurs, if git have to handle files with such an long path name.
Than, there will be "internal errors" poping up: "File or path name too long".
After that, thing getting more and more worse.
I did some investigations.
It seems, that the underlying "old" cygwin has some influence.
My test setup is Windows7 64bit "Git version 1.7.8-preview20111206". (also current one)
I've created some source folders with a length of 260+ long path names.
"git add" shows the following error:
fatal: unable to stat 'Adobe InDesign CS6 Server SDK/tools/benchmark/BenchmarkChartsConsole/src/com/adobe/ids/benchmark/
samples/dce/source/suribachi/src/suribachi/api/vo/action/tools/benchmark/BenchmarkChartsConsole/src/BenchmarkChartsConso
le-app.xml': No such file or directory
Of course, this file exists but has a long path.
Additionally I've tested this command ing Git bash:
"find . | wc -L"
Pops up this error (and much more):
find: ./Adobe InDesign CS6 Server SDK/tools/benchmark/BenchmarkChartsConsole/src/com/adobe/ids/benchmark/samples/samplec
lient-java-soap/src/com/adobe/ids/samples/sampleclient-aspnet-soap/sampleclient-aspnet-vb-soap/Default.aspx.vb: File or
path name too long
Than I've checked the find command within cygwin (CYGWIN_NT-6.1-WOW64 momo 1.7.15(0.260/5/3) 2012-05-09 10:25 i686 Cygwin)
Again "find . | wc -L" ... no errors,
result : 299
My blind guess:
So maybe just linking git against a newer cygwin should work?
Any help is appreciated, to get GIT work with long path names.
Activity
kusma commentedon Aug 2, 2012
Git for Windows doesn't link against Cygwin.
martin-w-kirst-hypoport commentedon Aug 3, 2012
Hi,
but there seems to be a relations between cygwin and Windows-Git package, because of the files shipped, right?
Any chance to get this issue fixed?
My technicak knowledge in C ist not that big ... can I help in any other way?
Regards
Martin
kusma commentedon Aug 3, 2012
Not quite. Git for Windows ships as a native Windows program. But we do ship a MSYS (a Cygwin fork) environment with it. However, git.exe is not an MSYS binary, and does not link to the MSYS-runtime.
martin-w-kirst-hypoport commentedon Aug 3, 2012
Thanks for clarification.
Any chances to adopt the "FIX" from cygwin?
I mean, the 'find' example works within Cygwin shipped environment, but doesn't work within Git's bash.
I assume, the sources are the same?
aberumen commentedon Aug 6, 2012
The following link has information on this issue:
https://groups.google.com/forum/?fromgroups#!msg/msysgit/9YIR6jlNB0Q/zHhPN3tejFkJ
Edit: This is addressed in the FAQs(https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions). The above link is referenced there aswell.
tmnuwan12 commentedon Apr 2, 2013
The information above save my life tracking down issue with Windows.
nitram509 commentedon Jun 16, 2013
On a hackathon our company had sponsored, we've created a patch for this issue. Frankly said, it's not yet worth to raise a pull request now, but we're working on ...
See the proof of concept screenshot: https://twitter.com/nitram509/status/345502581654704128
See our fork for the concrete patch and more details: https://github.com/hypoport/msysgit
the-Arioch commentedon Jun 16, 2013
great news. big thanks to your company!
Tibor17 commentedon Jul 1, 2013
Hi guys, I have the same problem. In the maven-surefire project we are releasing between Thu/Fri, and I found 5 files which could not be submitted to my repo due to this issue. I would appreciate a fix asap. Thx, Tibor
nitram509 commentedon Jul 1, 2013
Hi we're working on ... still 24 out of 632 integration tests are failing.
I can't promise any fix that soon. Please, be patient.
Regards
Martin
nitram509 commentedon Aug 5, 2013
Two Co-workers and I created a patch, which enables msysgit to handle long path names.
See attached file msysgit-issue52-proposal-20130804.patch for details.
We consider the patch as "proposal" and want to get some feedback.
Applying the patch to v.1.8.3 will pass every integration test, which un-patched version also does.
AFAIK, these things are still to do:
Please, give this patch a try and send feedback.
Thanks
Andi, Eric, Martin
See: msysgit/git#85
maoueh commentedon Dec 9, 2013
@nitram509 Where is the attachment exactly? Is the branch hypoport:issue52 a branch that I could use to test your patch? I have a repository with some files already too long for git when you like to give your patch a try.
nitram509 commentedon Dec 9, 2013
@maoueh Correct, the branch https://github.com/hypoport/git/tree/issue52 contains alle the relevant changes.
dscho commentedon Dec 30, 2013
Closing this issue as being superseded by msysgit/git#85.
5 remaining items
nitram509 commentedon Jan 13, 2015
@shiftkey
thanks for pointing this config option out.
Before, the core.longpaths wasn't set.
After I set
git config core.longpaths trueI was able to commit.Good Job! Thanks everybody. 👍
dscho commentedon Jan 14, 2015
@nitram509 your job is not quite done yet. The best place we could come up to tell users about the longpaths feature was the release notes, but obviously that message did not reach you. Therefore, you should figure out where the information about longpaths would have reached you and open a PR to make it so.
Tibor17 commentedon Jan 14, 2015
setting with --global just once
git config --global core.longpath
On Wed, Jan 14, 2015 at 8:57 AM, dscho [email protected] wrote:
dscho commentedon Jan 14, 2015
@Tibor17 no, this is not what I am talking about.
Look, users will not find this bug report, let alone your comment, and even then they will most likely be puzzled, I am sure you agree after re-reading the comment. We need to do a substantially better job than throwing out two short lines that are unclear.
We need documentation where users see it, and we need documentation that is easy to understand and enjoyable to read.
I believe that you tried to help, but I am convinced that we need somebody to contribute something well-crafted, and thought through, to achieve our common goal to make Git for Windows easier to use. At least that goal is what I think you and I have in common, yes?
Tibor17 commentedon Jan 14, 2015
What are you trying to tell me, that i should shut my mouth. Listen to
yourself first and then say something
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
On Wed, Jan 14, 2015 at 12:23 PM, dscho [email protected] wrote:
dscho commentedon Jan 14, 2015
@Tibor17 and now let's spend all that energy on contributing top quality patches.
the-Arioch commentedon Jan 15, 2015
Actually that could not be a good place. RelNotes are sometimes read before the upgrade, but no new user would have any reason to read them.
This belong to places like System Requirements/Limitations or FAQ or Typical Errors
And this belong to the very error messages GIT shows when meeting long paths - it has to suggest user to read about the aforementioned config option,
This said, why just not default it on and make the alerting of users unnecessary ?
the-Arioch commentedon Jan 15, 2015
Actually, everyone needs documentation that is informative. And after that, with lesser priority, are ease and pleasure.
So, why this option was not defaulted? What are cons and pros, what are gotchas ?
the-Arioch commentedon Jan 15, 2015
@dscho my uneducated guess is that you failed to diff @nitram509 and @Tibor17 :-D
dscho commentedon Jan 15, 2015
I wanted to be very careful to avoid problems. Please keep in mind that even the Explorer cannot handle files with too-long filenames – not even delete them.
dscho commentedon Jan 15, 2015
@the-Arioch you could always give it a shot and implement it. Historically, well-designed Pull Requests were handled quickly and command the respect of the maintainers. It was not unheard of features being included that the maintainers were unsure about at first, but their minds had been changed by excellent code contributions (which, to be honest, is much harder than simply commenting: talk is cheap 😀).
kblees commentedon Jan 15, 2015
FWIW, I've just updated the respective FAQ entry (https://github.com/msysgit/msysgit/wiki/Git-cannot-create-a-filedirectory-with-a-long-path)
dscho commentedon Jan 15, 2015
@kblees thank you for your continued top quality contributions! Believe me, I appreciate that very, very much.
nitram509 commentedon Jan 17, 2015
@kblees thank you for updating the FAQ
dolmen commentedon Jun 21, 2016
The wiki page has moved here.