1

I use an Ubuntu VM over Windows 8 using VMWare and while using git I got an error of

error: bad index file sha1 signature
fatal: index file corrupt

When trying to commit.

Now, I found ways to fix this (the primary one, deleting .git/index and retrying, seems a bit of a workaround) but I want to understand what causes this error (Partly because they tend to work in a random way).

I made an experiment and run a couple of commands in ~/ (a regular directory) and in /mnt/hgfs/Shared with host/ (the shared directory with the Windows host, which is my laptop).

In the regular directory it worked flawlessly, but in the shared directory it failed with the above error on the commit message.

The commands are:

mkdir trial
cd trial
echo hello > world.txt
git init
git add .
git commit -m "msg"

Now I wonder, why does it matter that the directory is shared?
And in general, what causes this error? Which sha1 signature is the index file compared to (I didn't find anything that could store such a signature when running tree .git)?

Neo
  • 3,534
  • 2
  • 20
  • 32
  • 1
    The index file stores _its own_ SHA1 signature exactly so that it can detect when it's been corrupted. Its the trailer of the index file itself. Many shared filesystem platforms that do a bidirectional synchronization end up corrupting git repositories. Don't use them. – Edward Thomson Oct 30 '17 at 11:53
  • @EdwardThomson How do they corrupt the file? If they sync the file as a whole, I assume the signature will stay and nothing should break... – Neo Oct 30 '17 at 12:17
  • I don't know the details about their shared filesystem driver to know what they're doing wrong. But fundamentally, they're emulating a posix like filesystem backed by a Windows NTFS filesystem, it feels like there's a lot of sharp edges there. – Edward Thomson Oct 30 '17 at 13:01

1 Answers1

0

Edward Thomson's comment is correct—you can see this from the error message and the corresponding source code function verify_hdr, which includes these lines:

git_SHA1_Init(&c);
git_SHA1_Update(&c, hdr, size - 20);
git_SHA1_Final(sha1, &c);
if (hashcmp(sha1, (unsigned char *)hdr + size - 20))
        return error("bad index file sha1 signature");

(the magic constant 20 is the size in bytes of the computed SHA1).

What's not at all clear is what, in the sharing of the file, is causing the binary data in the index file to be modified inappropriately. But clearly it is being modified inappropriately, and this VMWare sharing mechanism does not work for this case.

torek
  • 448,244
  • 59
  • 642
  • 775
  • Yeah, I don't know exactly what's going wrong here either. The semantics are standard: open the index lock file, write to it, move it into place as the new index file atomically. If I had to guess (and I do), the VMWare shared folder layer is (on the Windows side) doing I/O and bypassing the filesystem locking. IIRC, this can give you a torn read, where the file contents are changed as you're reading it, which sounds like exactly what's going on here. – Edward Thomson Oct 30 '17 at 21:49
  • Whatever the reason - I agree - the VMWare sharing mechanism does not work for this case and should be avoided. – Edward Thomson Oct 30 '17 at 21:49