windows - if git index.lock exist, can I safely delete it, or are more actions needed to verify integrity?

Question

Over the last couple of weeks I got a message about index.lock to exist a few times.

Deleting that file is mentioned as solution in git index.lock File exists when I try to commit, but cannot delete the file

Is deleting that file enough, or are there other actions I should need to do (are there ways to verify integrity and such?).

This is on a Windows x64 system (fully patched) with git commandline tools, TortoiseGIT and SourceTree installed.

Answer 1

None of the other answers mention what that index.lock is for.
Yet, it is documented in a Git distribution, under the file "Documentation/technical/api-lockfile.txt".

Is deleting that file enough?

Following that documentation, it appears that deleting is enough.

lockfile API

The lockfile API serves two purposes:

• Mutual exclusion.
  When we write out a new index file, first we create a new file $GIT_DIR/index.lock, write the new contents into it, and rename it to the final destination $GIT_DIR/index. We try to create the $GIT_DIR/index.lock file with O_EXCL so that we can notice and fail when somebody else is already trying to update the index file.

• Automatic cruft removal.
  After we create the "lock" file, we may decide to die(), and we would want to make sure that we remove the file that has not been committed to its final destination.
  This is done by remembering the lockfiles we created in a linked list and cleaning them up from an atexit(3) handler. Outstanding lockfiles are also removed when the program dies on a signal.

On Windows, there shouldn't be a permission issue (like one Git tool creating that file as 'root').
The only issue would be for one of your Windows tools to:

• either run under the System account instead of the user account,
• or start staging files (meaning creating an index and creating the index.lock file), and having another tool to start staging as well files in the same repo.

Considering that file is creating under the O_EXCL locking scheme, it is likely it cannot be created because it is locked by another PID.
As mentioned here:

The only thing O_EXCL does is cause the call to fail if the file exists and O_CREAT is specified.

---

Update August 2015, for git 2.6+ (Q3 2015)

The "lockfile" API has been rebuilt on top of a new "tempfile" API.

See commit 9e90331, commit 18a3de4, commit ebebeae, commit 00539ce, ...(huge list), commit 2db69de (10 Aug 2015) by Michael Haggerty (mhagger).
^{(Merged by Junio C Hamano -- gitster -- in commit db86e61, 25 Aug 2015)}

The tempfile API allows temporary files to be created, deleted, and atomically renamed.
Temporary files that are still active when the program ends are cleaned up automatically.
Lockfiles are built on top of this API.