git checkout error: unable to create file

Question

While cloning a git repository from Linux to a Windows system, I am getting the following error in checkout the phase:

$ git clone gituser@serveraddr:/git/git_repo.git git_WA
Cloning into 'git_WA'...
gituser@serveraddr's password:
remote: Counting objects: 500846, done.
remote: Compressing objects: 100% (118676/118676), done.
remote: Total 500846 (delta 307739), reused 483023 (delta 291136)
Receiving objects: 100% (500846/500846), 907.54 MiB | 9.04 MiB/s, done.
Resolving deltas: 100% (307739/307739), done.

error: unable to create file RealR**************************************************************************************************************************************************************************************************************validation.xml (No such file or directory)
Checking out files: 100% (441329/441329)
Checking out files: 100% (441329/441329), done.
done.

Case-2: Cloned as bare repo, checked-out all from bare repo locally => Same error.

Case-3: Clone the repo in C:\ directly, checkout successful, No error.

-> It looks like problem with filename/filepath length limitation.

Case-4: checkout the same files from SVN repo. Able to checkout at any location without any problem. Hence no problem from windows side. (Yes, l have data in SVN and GIT both, I just migrated from SVN to GIT).

Hence, the problem has to be within msysgit, some filepath length limitation. Can path length in gitclient/msysgit be tweaked?

Edit1: All operation tried with TortoiseGIT client v1.8.0 and git-bash: git version 1.8.0.msysgit.0.
Edit2: Added the actual command used while cloning.

Stilly

When the file has special chars. Refer to Git pull error: unable to create file (Invalid argument) – Briarroot

Answer 1

Try:

git config --system core.longpaths true

This will allow it to checkout the files even with longer filepaths. The issue with this would be when you try to delete it, as Windows will not allow to delete a path longer than it's allowed threshold. The workaround to that is to rename the folders in the local repository, so that the overall length of the path is lessened. For example, a path that is alpha/beta/gamma/universe.txt, can be limited to 1/2/3/universe.txt, so that it's length is under the windows filesize threshold.

Chimkent

run that from a Git Bash with elevated privilege (run as admin) – Goodhen

Answer 2

I experienced similar problems when checking out a project into a Windows directory that had a 67- (Windows) or 76- (cygwin) character base path - when added to the path-length of the checked out files, it exceeded Windows' path-length limit:

git checkout -f HEAD
error: unable to create file <194-character filepath> (No such file or directory)
fatal: cannot create directory at '<187-character directory path>': No such file
or directory

I solved the problem by checking out the git repository to c:\git, which, at 6 or 15 characters in length, kept the maximum path-length under the Windows limit.

Minutiae

This was an issue for myself. A good indicator for this being the issue is that one file with a particularly long name will fail after other files succeed. – Promiscuity

Answer 3

Many Windows APIs are limited to 260 symbols for file path name. So git can't create files with names longer than 260 symbols. NTFS file system actually supports longer names (32k) but there is no easy way to allow long names for programs.

Workaround 1: move your project to a new location, closer to disk root. Advantage:

• Everything should work fine (assuming there no files with path longer 260)

Disadvantage:

• You have to change project location

Workaround 2: create a Junction to your project folder from a folder that is closer to disk root and do git clone from the junction folder. You can do this with mklink command or Link Shell Extension.

Advantage:

• You can have long file names (greater than 260)
• You can preserver project location
• You may safely delete junction after initial cloning (if you don't need to work with files that violate 260 symbol limit at original location)

Disadvantage:

• Full file name at junction still have to be less 260 symbols. Otherwise this solution will not help.
• If you want to modify the files with long path you need to use tools that are compatible with that OR fallback to modifying "short path" copy

Biliary

Or you can change registry to allow longer paths: lifehacker.com/… – Identity

Answer 4

The only suggestion I saw, considering a similar issue, was:

Workaround: use http://www.cygwin.com/

Or at least check if a checkout in a git-bash session of msysgit works better.

---

Update May 2015 (2 years later):

Note: the latest 2.4.1 git-for-windows proposes:

core.longpaths::

Enable long path (> 260) support for builtin commands in Git for Windows.
This is disabled by default, as long paths are not supported by Windows Explorer, cmd.exe and the Git for Windows tool chain (msys, bash, tcl, perl...).
Only enable this if you know what you're doing and are prepared to live with a few quirks.

Hollands

I have tried all these operations with git-bash: git version 1.8.0.msysgit.0, and TortoiseGIT client v1.8.0 which internally uses the same msysgit. Edited the question with same info. – Stilly

@Stilly cygwin would offer a completely different environment, which should support longer path length (#3144582). Windows-based git-client cannot get path the Windows path length limitation. – Hollands

I have tried with git-bash which is always run with cygwin environment. Also additionally, I have independent cygwin installed on my system. So, tried the checkout with cygwin as well, but facing exact the same issue. Am I doing wrong anywhere. – Stilly

@rohit: Note, it is my understanding that git-bash is different from cygwin (again, #3144582). But the same limitation might apply (cygwin.com/ml/cygwin-patches/2005-q1/msg00084.html), indeed. – Hollands

Answer 5

Use Windows PowerShell. Worked for me.

Readus