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.

Answer 1

Use Windows PowerShell. Worked for me.

Answer 2

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

Answer 3

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 to c:\git, which, at 6 or 15 characters in length, kept the maximum path-length under the Windows limit.

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.

Answer 5

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.