Git error unable to create file

When Bamboo checks out changes from repositories using the Windows Git.exe executable, the task fails and the following appears in the job log

java.lang.RuntimeException : com.atlassian.bamboo.plugins.stash.repository.StashRepositoryException: com.atlassian.bamboo.repository.RepositoryException: Checkout to revision <hash> has failed.command 'C:Program FilesGitcmdgit.exe' checkout -f master failed with code 1. Working directory was [<job working directory>]., 
stderr: error: unable to create file <filename>: Filename too long error: unable to create file

According to the msysgit wiki on GitHub and the related fix this error, Filename too long, comes from a Windows API limitation of file paths having 260 characters or fewer.

To resolve this issue, we could change the Windows default 260 character limit in the Windows registry or by configuring the core.longpaths workaround in git config.

Starting in Windows 10 (Windows Server 2016), version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behaviour. We need to set the Windows default 260 character limit by updating the registry as mentioned here. 

Go to the registry key ComputerHKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystemLongPathsEnabled (Type: REG_DWORD) must exist and be set to 1.

    New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlFileSystem" `
   -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force

The git configuration setting can be used for Windows versions lower than 2016 and Windows 10.

For Git configuration run the following command from GitBash or the Git CMD prompt:

git config --system core.longpaths true

This will allow file paths of 4096 characters.

git config --global core.longpaths true

I am trying to sync remote repo with local repo but getting following errors. Some files (which have not extention) are not getting sync with local repo on WINDOWS machine, but I could sync successfully on MAC machine.

Is there any configuration settings in WINDOWS to handle such case?

1. Using TortoiseGit
2. Windows 7 64 bit machine

ERROR DETAILS

git.exe clone     --progress -v  "https://github.com/xxxx/xxxxx.git" "C:DataGitHubsimilityvishesh-common"

Cloning into 'C:DataGitHubsimilityvishesh-common'...
POST git-upload-pack (200 bytes)
remote: Counting objects: 3912, done.
remote: Compressing objects: 100% (487/487), done.
Receiving objects: 100% (3912/3912), 2.70 MiB | 567.00 KiB/s, done.
Resolving deltas: 100% (1578/1578), done.
remote: Total 3912 (delta 409), reused 0 (delta 0)
Checking connectivity... error: unable to create file kickstarter/parsers/data/kickstarter/campaigndetails/_projects_1030050305_fantasy-trilogy-spin?ref=users (Invalid argument)
error: unable to create file kickstarter/parsers/data/kickstarter/campaigndetails/_projects_1030295038_laser-dogs?ref=users (Invalid argument)
error: unable to create file kickstarter/parsers/data/kickstarter/campaigndetails/_projects_1030315317_arizona-native-bird-painting-series?ref=users (Invalid argument)
error: unable to create file kickstarter/parsers/data/kickstarter/campaigndetails/_projects_1030315317_native-birds-ii?ref=users (Invalid argument)
error: unable to create file kickstarter/parsers/data/kickstarter/campaigndetails/_projects_1030552097_ikeyboard-0?ref=users (Invalid argument)
error: unable to create file kickstarter/parsers/data/kickstarter/campaigndetails/_projects_1030552097_ikeyboard?ref=users (Invalid argument)
error: unable to create file kickstarter/parsers/data/kickstarter/campaigndetails/_projects_1030552097_only-you-can-prevent-computercide?ref=users (Invalid argument)
error: unable to create file kickstarter/parsers/data/kickstarter/campaigndetails/_projects_1030552097_vector-cupholder-protect-your-laptop-and-your-lap?ref=users (Invalid argument)
error: unable to create file kickstarter/parsers/data/kickstarter/campaigndetails/_projects_103055429_death-of-an-angel?ref=users (Invalid argument)
error: unable to create file kickstarter/parsers/data/kickstarter/campaigndetails/_projects_1030650665_rachel-vanslyke-making-a-new-record-together-we-ca?ref=users (Invalid argument)
error: unable to create file kickstarter/parsers/data/kickstarter/campaigndetails/_projects_1030835091_russian-trucks-of-world-war-two?ref=users (Invalid argument)
error: unable to create file kickstarter/parsers/data/kickstarter/campaigndetails/_projects_1031873800_prop-expansion-next-level?ref=users (Invalid argument)
error: unable to create file kickstarter/parsers/data/kickstarter/campaigndetails/_projects_1031873800_prop-project-expansion?ref=users (Invalid argument)
error: unable to create file kickstarter/parsers/data/kickstarter/campaigndetails/_projects_1099860912_yaw-clock?ref=users (Invalid argument)
error: unable to create file kickstarter/parsers/data/kickstarter/campaigndetails/_projects_1099992656_heavenly-sight-a-vision-out-of-blindness?ref=users (Invalid argument)
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status' and retry the checkout with 'git checkout -f HEAD'

git did not exit cleanly (exit code 128) (21746 ms @ 29-09-2014 13:32:13)

This problem is getting weirder.

My original post follows, but here is the new thing I discovered:

I executed

git push

and it gave me its usual error:

Counting objects: 9, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 588 bytes, done.
Total 5 (delta 4), reused 0 (delta 0)
remote: error: unable to create temporary file: No such file or directory
remote: fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To USER@REMOTE:/git/PROJECT.git
 ! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'USER@REMOTE:/git/PROJECT.git'

So being overly optimistic, I thought maybe the «—verbose» option would give me some details, so I immediately tried again:

git push --verbose

and this time it worked:

Pushing to USER@REMOTE:/git/PROJECT.git
Counting objects: 9, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 588 bytes, done.
Total 5 (delta 4), reused 0 (delta 0)
To USER@REMOTE:/git/PROJECT.git
    87d6996..1cae8b3  master -> master
updating local tracking ref 'refs/remotes/origin/master'

so it’s just totally flaky. I’m starting to suspect that git just doesn’t like LDAP.

Original post:

We’re transitioning from cvs to git, and I have a test setup where I have a git server that authenticates users with LDAP, let’s call it REMOTE, and then my personal machine, let’s call it LOCAL. Both machines are Macs. All employees of the company (including me) are members of a group I’ll cleverly call GROUP.

I ssh’d to REMOTE as me and created a git repository there in a folder named /git/PROJECT.git using cvs2git.

Then, back on LOCAL, I did:

git clone USER@REMOTE:/git/PROJECT.git

which was fine. On my Mac («LOCAL») I then edited a few files, deleted a couple, and did

git -a FILES
git rm FILES
git commit -m 'COMMENT'

and life was good.

Then (still on LOCAL) I executed:

git push

to push my changes from LOCAL back to REMOTE and got this:

Counting objects: 19, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (10/10), 1.46 KiB, done.
Total 10 (delta 8), reused 0 (delta 0)
remote: error: unable to create temporary file: No such file or directory
remote: fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To USER@git-server-co.local:/git/PROJECT.git
 ! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'USER@git-server-co.local:/git/PROJECT.git'

I researched this problem and it sounded like it might be that might $TMPDIR is wrong, so I ssh’ed to REMOTE, created a directory named /git/tmp, made sure it had write permissions, edited my .bashrc, and set $TMPDIR to /git/tmp.

Back on LOCAL, if I execute

ssh USER@REMOTE echo $TMPDIR

I correctly see the response

/git/tmp

If I ssh to REMOTE and check file permissions, here’s what I see:

ls -l /git
drwxrwxrwx  USER GROUP   tmp
drwxrwsr-x  USER  GROUP   PROJECT.git

ls -l /git/PROJECT.git

all files are rw for owner (me) and group

What else could be causing this error?

p.s. As is the standard on Macs, if I execute:

ssh ADMIN@REMOTE
cd /
ls -l

I see symbolic links: tmp -> /private/tmp, var -> /private/var, and etc -> /private/etc. I adjusted the permissions and ownership so now they are set to:

lrwxr-xr-x   USER   GROUP   etc -> /private/etc
lrwxr-xr-x   USER   GROUP   tmp -> /private/tmp
lrwxr-xr-x   USER   GROUP   var -> /private/var

I also updated the permissions of the actual folders, so if I execute:

cd /private
ls -al

I see:

drwxr-xr-x   USER   GROUP   etc
drwxrwxrwt   USER   GROUP   tmp
drwxr-xr-x   USER   GROUP   var

And finally, if I :

cd /private/var
ls -al

I see:

drwxrwxrwt    USER   GROUP   tmp

I was doing some routine updates to Drupal modules today when I got a rather peculiar error: git was unable to create a file called ‘index.lock’. I don’t know what a lock file is, or why Git even needs to create one, so it caught me by surprise. Reviewing my own terminal, though, and after consulting a thread over at Stack Overflow, It’s all clear to me how I ended up where I did. In the end, I fell into the ever enduring trap of not listening to my terminal. Let’s start at the beginning, though. Here’s how I managed to find myself with this error:

How to make a commit:

I make commits without using Git’s default text editor for my commit message—that is, I usually make my messages inline. I’ve long done this because command line text editors often require memorizing a set of unique commands that differ from OS defaults (such as ctl-s to save). Memorizing all of the git-specific commands alone is more than enough stress on the brain—why bother with anything more? So this is how I usually do my commits:

$ git commit -a -m 'this is my commit message' 

Now, it just so happens that every now and then, I fumble on my keyboard and mistype my entry. Today, I accidentally hit return before I got to the inline message:

$ git commit -a

Many of you will know that if you don’t give your commit message inline, Git will open your default command line editor and ask for your commit message either way. In my case, I set Git to default to Nano (which I find more intuitive than Vi, Vim, or even Emacs). Without the inline commit message, I suddenly found myself staring at a Nano edit screen. Now, I’ve had enough experience with Nano to know how to save a file and exit the program. Under normal circumstances, saving a commit message and exiting the editor will simply bring you back to the command prompt, at which point you can proceed with a push. As is occasionally the case though, I was so focused on getting to the push that I didn’t take notice of the output once I had exited Nano:

$ git commit -a
Use "fg" to return to nano.

[1]+  Stopped                git commit -a
$

This should have been the first red flag. The commit obviously didn’t finish, and I was being prompted to return to Nano. Blissfully ignorant, I went ahead and made my push. The push went as expected (you don’t have to finish your commit to push—Git just pushes everything that’s already committed), so I moved on to checkout another branch for a merge. That’s when I got the following error:

$ git checkout some-branch
fatal: Unable to create 'project_path/.git/index.lock': File exists.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.

Whaaaaaaaaaaat?

This should have been the second red flag—although, the wording in the error could have been better. It should probably read a little more like this: «A git process is probably running in the background and hasn’t been terminated. If not, this may mean a git process crashed in this repository earlier…» The bit about ensuring that no other git process is running is the real point, though. Again, if you don’t actually read the output on your terminal, you can get a bit turned around. At this point, I probably could have put 1 and 1 together and should have realized that there was a problem with my commit message—namely, that Nano was still running in the background, and that I hadn’t actually finished my commit (a git status would have confirmed this as well). Failing to engage with my terminal, though, I went straight to Stack Overflow (via DuckDuckGo). The thread I found had no «accepted» answer, but there were several suggestions to simply remove the index.lock file. A few, however, had suggested heeding the words of the error and confirming whether any git processes were running. Here’s what I got:

$ ps -ef | grep git
dhmpsan+ 13825 13708  0 18:03 pts/1    00:00:00 git commit -a
dhmpsan+ 13846 13825  0 18:03 pts/1    00:00:00 editor /project_path/.git/COMMIT_EDITMSG
dhmpsan+ 15188 13708  0 18:09 pts/1    00:00:00 grep git

And now it all starts to come together. My commit and my commit message are both still running. One solution would be to simply kill the processes; a better solution might be to finish them out, though. I must have exited Nano without actually terminating the application (more on that in a bit); had I actually finished my commit message, the commit process also would have resolved and everything would be hunky dory. Probably best to go finish that commit message. If you pay close attention to the processes listed above, you can see that the commit message is being stored by Git in a file called COMMIT_EDITMSG. Let’s open that with Nano and see if we can’t finish it out. After navigating to your .git folder, open the file with your editor:

$ nano COMMIT_EDITMSG

You should get something like this when you open Nano:

FILE COMMIT_EDITMSG is being edited (by servername with nano 2.5.3, PID 17212); continue?
Y Yes
N No      ^C Cancel

YES!!—edit it! Once you edit this, save and exit the text editor appropriately, the process should terminate and your index.lock file issue should be resolved. Interestingly enough, though, this didn’t finish out the commit I had started earlier. It terminated the processes, but I still needed to commit once more. This time, I opted to add my commit message inline.

But… beyond not reading the output of my terminal, what was the cause of all this? How did I get out of Nano while it was still running?

Butterfingers: Ctl-X vs Ctl-Z in Nano

The X and Z keys are right next to each other on the keyboard. If you’re not careful, you can hit Z when you intend to hit X. For Nano, that’s a big difference. Ctl-X will exit you from the editor; Ctl-Z will put the current process in the background. Ctl-Z can give you the impression that you’ve left the application when in actuality you haven’t. If you’re the kind of person who actually listens to your terminal, you’ll probably catch on to this. If you’re whizing through your workflow, as I often do, you might find yourself in a pickle, though.