8000 Repository.Clone fails with "Filename too long" error · Issue #1374 · libgit2/libgit2sharp · GitHub
[go: up one dir, main page]

Skip to content

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

Closed
panuganti opened this issue Oct 3, 2016 · 22 comments
Closed

Repository.Clone fails with "Filename too long" error #1374

panuganti opened this issue Oct 3, 2016 · 22 comments

Comments

@panuganti
Copy link

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 ?

@carlosmn
Copy link
Member
carlosmn commented Oct 5, 2016

core.longpaths is something that's specific to the Git for Windows distribution of git. libgit2 does not support it, and neither does most of Windows.

@panuganti
Copy link
Author

So, what is the solution to this problem ?
Setting global config should be supported by LibGit2Sharp. Is there a way ?

@Stepan222
Copy link

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.

@klyse
Copy link
klyse commented Feb 6, 2018

Any update on this problem?

@ethomson
Copy link
Member
ethomson commented Feb 6, 2018

Any update on this problem?

Nope! Still fails (just like 99% of all Windows applications)

@coderitual
Copy link

Maybe you will be this 1% ;)

@MrShoenel
Copy link
MrShoenel commented Feb 22, 2019

I have now successfully circumvented the problem in Windows 10 by disabling the 260 character limit on NTFS (see below). Setting git config --system core.longpaths true did not work for (still set it anyways). I have altered the group policy as per this post (quote the relevant part here):

Since Windows 10 there's another option by removing MAX_PATH limitation§. You can enable it by setting HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled in registry or set Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths in group policy

Edit: My problem was with opening the repository, not necessarily with cloning it. I had it previously cloned with git clone -c core.longpaths=true https://github.com/apache/hadoop.git and then opened it with libgit2sharp

@andrew-allen-work
Copy link
andrew-allen-work commented Apr 23, 2019

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 :)

@MrLiu0635
Copy link

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.
When I use win10&vscode&git as develop envirenment, it can do work well.
And my project is base on dotnet-core-2.0 , it can do well on 260 or more characters as creating folders/files.
My english is not good, and i hope i have made myself clear.

@noontz
Copy link
noontz commented May 19, 2020

I'm wondering why this issue is closed.
On windows 10 with no longpath settings what so ever:
Cloning from gitbash / git for windows - no problem.
Cloning from VS - no problem
Cloning with libgit2sharp - big problem

@andrew-allen-work
Copy link

I would love to know also :-)

@ethomson
Copy link
Member

I'm wondering why this issue is closed.

It's not.

Screen Shot 2020-05-19 at 14 57 30

@noontz
Copy link
noontz commented May 20, 2020

@ethomson UPPS.... Sorry...

@ethomson
Copy link
Member

No problem! Sorry this is such a thorny problem. There's been some work started in libgit2 to address it.

@smoczas
Copy link
smoczas commented Jul 7, 2020

Is there any ETA for the fix to this issue?

@alinmircea
Copy link
alinmircea commented Jul 20, 2020

@carlosmn worst attitude. "bla bla windows sucks", guess what git works just fine if "git config --system core.longpaths true"
What is the issue in libgit2sharp ? Why is it different ? Can git2sharp support it ?

@rupreck
Copy link
rupreck commented Oct 14, 2020

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.

@Solairw
Copy link
Solairw commented Mar 12, 2021

Try using with CloneOptions with flag IsBare = true. This solved the issue for me.

@DewaldNel
Copy link

Try using with CloneOptions with flag IsBare = true. This solved the issue for me.

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?

@sulkowsj
Copy link

Looks core.longpaths are supported since libgit2 v1.2.0.
Is there any blocking point to support it in libgit2sharp?

@dcworldwide
Copy link

Any update?

@bording
Copy link
Member
bording commented Nov 24, 2024

As of LibGit2Sharp 0.27.0, it should be respecting the core.longpaths setting, so I'm going to close this issue as fixed.

@bording bording closed this as completed Nov 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

0