-
Notifications
You must be signed in to change notification settings - Fork 899
Repository.Clone fails with "Filename too long" error #1374
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
|
So, what is the solution to this problem ? |
You must try using Long Path Tool. This tool enables you to rename, delete, or move the file easily. I have used it multiple times and 8000 it works perfectly. |
Any update on this problem? |
Nope! Still fails (just like 99% of all Windows applications) |
Maybe you will be this 1% ;) |
I have now successfully circumvented the problem in Windows 10 by disabling the 260 character limit on NTFS (see below). Setting
Edit: My problem was with opening the repository, not necessarily with cloning it. I had it previously cloned with |
I have this problem when trying to use GitVersion with teamcity. When using a build in teamcity with the windows git client checking out repos with long paths enabled in git configs, works fine. However, I cannot fix it for GitVersion or more specifically the referenced libgit2sharp libraries. I even built a 2016 svr to run a Teamcity agent on and set git config --system core.longpaths true as our teamcity build server runs on 2012 R2 Server. I also set the policy to enable on the 2016 server with the TeamCity agent as @MrShoenel did above. This library is used by gitversion and on windows it breaks ,this must be fixable, would be happy to do it if someone can point me in the right direction... (And btw I cannot reduce longpaths in the VS solutions as it is a website with tons of node modules... ). lastly when I run git version against an already cloned local copy on windows 10 it works fine. Any pointers to finding a fix or work around to this would be greatly appreciated :) |
So sorry to mention this issue again. But I have to. I used libgit2sharp in my project. When users try to break 260 character limit, error throws. |
I'm wondering why this issue is closed. |
I would love to know also :-) |
@ethomson UPPS.... Sorry... |
No problem! Sorry this is such a thorny problem. There's been some work started in libgit2 to address it. |
Is there any ETA for the fix to this issue? |
@carlosmn worst attitude. "bla bla windows sucks", guess what git works just fine if "git config --system core.longpaths true" |
Nodegit (which also binds to libgit2) release v26.5 was released in March and included the merged PR #5347 supporting this although this is not yet merged to master in libgit2. See: nodegit/nodegit#1748 Is this an option for libgit2sharp? Lack of support for this is becoming increasingly a problem with various project package components (including node_modules) and testing frameworks with deep descriptive paths unable to be consumed. |
Try using with CloneOptions with flag |
This alone makes the output zip file unusable as it is saved in an encrypted Git format. Do you have any other changes that you made with this that maybe prevented this issue? |
Looks core.longpaths are supported since libgit2 v1.2.0. |
Any update? |
As of LibGit2Sharp 0.27.0, it should be respecting the core.longpaths setting, so I'm going to close this issue as fixed. |
My attempt to use Repository.Clone fails with the error..
LibGit2Sharp.NameConflictException: Failed to stat file '<..some long path..>': The filename or extension is too long.
Is there any solution for this ?
I believe, I need to set core.longpaths in the global config to true. Is there anyway to do that ?
The text was updated successfully, but these errors were encountered: