Git init error fatal: cannot copy hooks/post-commit.sample, No such file or directory

Question

Today I discovered a weird issue with Git. On three of our build agent machines we got the following error after a git init:

fatal: cannot copy 'C:\Program Files (x86)\Git/share/git-core/templates/hooks/post-commit.sample' to 'C:/MyRepo/.git/hooks/post-commit.sample': No such file or directory

I checked that the file in Program Files exists and all the file permissions are correct.

Then I removed all the sample files from C:\Program Files (x86)\Git/share/git-core/templates/hooks folder, and got another error after git init

error: unable to open C:/MyRepo/.git/HEAD.lock for writing

I tried to reinstall git but this did not help.

But after I rebooted the machine issue had gone.

When I reboot other two machines the issue had gone as well without any other actions.

So the question is why is that happened suddenly and how to prevent this in future?

UPD: One more symptom. Maybe this helps to identify the issue.

I tried to run chkdsk on the problematic drive and I get

The type of the filesystem is RAW.
CHKDSK is not available for RAW drives.

After reboot it shows as a NTFS again...

Answer 1

The message "type of the filesystem is RAW." is worrisome, and could indicate some kind of disk failure, as described in "CHKDSK: "RAW filesystem" message"

Sometimes, the volume fails in such a way that it becomes RAW.

In most cases the failure will be associated with a sudden reboot (per power failure or the STOP error).

Several causes are possible: partition table, LDM database, or the volume boot sector corruption, or (on the NTFS volume) when certain records in both MFT and MFT mirror are damaged beyond easy recognition.

You can try to fix the MTF (as described here, using TestDisk), but you can first try and put your repo on another partition/disk and see if your build agent behaves correctly then.

See also "CHKDSK is not available for RAW drives" or "On a failing hard drive, I am able to view data but unable to copy it - why?", for similar descriptions.

---

Like in this question, make sure there isn't an environment variable GIT_DIR previously set, that your build agent (Jenkins? Hudson? TeamCity?) would pick-up when doing its git init.

Unsetting GIT_DIR systematically before the git init would make sure it tries to init a repo where it is supposed to.