Windows, Pathname too long (>256 chars)

[nitram509]

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.

[kusma]

Git for Windows doesn't link against Cygwin.

[martin-w-kirst-hypoport]

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]

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]

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]

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]

The information above save my life tracking down issue with Windows.

[nitram509]

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]

great news. big thanks to your company!

[Tibor17]

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]

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]

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:

• writing a test
• split xutftowcs_path into separate functions for character conversion and prefixing - so de-prefixing can be avoided at some places
• checking upper array boundaries

Please, give this patch a try and send feedback.

Thanks
Andi, Eric, Martin

See: msysgit/git#85

[maoueh]

@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]

@maoueh Correct, the branch https://github.com/hypoport/git/tree/issue52 contains alle the relevant changes.

[dscho]

Closing this issue as being superseded by msysgit/git#85.

[dscho]

@FGranados please do not post off-topic comments. I deleted it again.

[fliegera]

Is this really solved? I am working on Version 1.9.4 and facing the same Problem, when Path-lenght is > 260

[Tibor17]

no issue with 1.9.5 👍

[nitram509]

nope, still not working 👎

user@host /g/Temp/0001 (master)
warning: unable to access '0002/0003/0004/0005/0006/0007/0008/0009/0010/0011/0012/0013/0014/0015/0016/0017/0018/0019/0020/0021/0022/0023/0024/0025/0026/0027/0028/0029/0030/0031/0032/0033/0034/0035/0036/0037/0038/0039/0040/0041/0042/0043/0044/0045/0046/0047/0048/0049/.gitignore': Filename too long
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)

        0001.txt

nothing added to commit but untracked files present (use "git add" to track)


$ git --version
git version 1.9.5.msysgit.0

$ uname -a
MINGW32_NT-6.2 HOST 1.0.12(0.46/3/2) 2012-07-05 14:56 i686 unknown

Windows 8.1 Professional 64bit 

[shiftkey]

@nitram509 what does this return for your repository?

git config core.longpath

[nitram509]

@shiftkey
thanks for pointing this config option out.

Before, the core.longpaths wasn't set.
After I set git config core.longpaths true I was able to commit.

Good Job! Thanks everybody. 👍

[dscho]

@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]

setting with --global just once
git config --global core.longpath

On Wed, Jan 14, 2015 at 8:57 AM, dscho notifications@github.com wrote:

@nitram509 https://github.com/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.

—
Reply to this email directly or view it on GitHub
#52 (comment).

[dscho]

@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]

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 notifications@github.com wrote:

@Tibor17 https://github.com/Tibor17 no, this is not what I am talking
about.

Look, users will not find this bug report, let alone your 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?

—
Reply to this email directly or view it on GitHub
#52 (comment).

[dscho]

@Tibor17 and now let's spend all that energy on contributing top quality patches.

[the-Arioch]

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

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]

we need documentation that is easy to understand and enjoyable to read.

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]

@dscho my uneducated guess is that you failed to diff @nitram509 and @Tibor17 :-D

[dscho]

This said, why just not default it on and make the alerting of users unnecessary ?

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]

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,

@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]

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]

@kblees thank you for your continued top quality contributions! Believe me, I appreciate that very, very much.

[nitram509]

@kblees thank you for updating the FAQ

[dolmen]

The wiki page has moved here.