git: Can I always safely attempt to delete index.lock?

Question

I've found a number of similar questions, but not this exact one. For reference, here are some similar issues:

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

Git - fatal: Unable to create '/path/my_project/.git/index.lock': File exists

I am programmatically using git across a number of repos, and the (Windows) app sits in a loop doing "git pull", "git commit" and "git push", keeping a number of repos in sync with local and remote data changes.

On occasion my app runs into the "index.lock file exists" problem. The app is used in various environments where the computer may indeed just be shut down randomly...long story.

Question: can I simply code up an attempt to delete index.lock any time the app encounters this error? Is that "safe"?

I am concerned about timing issues. For example, does git hold this file open while it is in use (so my delete attempt will correctly fail) or could deleting a non-orphaned index.lock file succeed and then corrupt my repo? Or will deleting index.lock out from under an index update simply cause that update to fail, and it needs to be attempted again the next time the app loops through the pull?

Other answers say things like "make sure no git processes are running before deleting index.lock", but that doesn't really work in the real world because it introduces timing problems - i.e. the app looks and there are no "git" processes, but before it deletes index.lock a git process starts.

Any insight - or out of the box suggestions - would be much appreciated. Thanks!

Answer 1

No, you cannot. The lock file is there for a reason, and that reason is to prevent other processes from attempting to write to the index when it's in use. The way Git lock files work is that Git creates a lock file, writes the new data to the lock file, and then atomically renames the old file over the new one.

If you delete the lock file, another process that is attempting to write the index will fail to do so (since the rename(2) will fail), and that process could be something like a git commit or other user-visible process. If the index is being written due to a git add or the like, you'd prevent that process from completing or destroy its changes, and the item would not be added. In addition, if you're working on Windows, it may not even be possible to delete a file that's in use.

If you absolutely need to programmatically write to a repository and avoid this problem without user interaction, then you need to use libgit2 or one of its wrappers and write a separate index file for your programmatic process. Ideally you would use a bare repository for that purpose as well, since the working tree would likely be irrelevant. That's the only way to guarantee that this problem won't occur.

As a side note, you will likely experience data loss if the computer is just shut down randomly. Git can sync object files with core.fsyncObjectFiles, but it doesn't fsync other data, and you still can end up with corrupted refs or an index file full of zeros. Neither Git nor libgit2 are designed to handle this case.