how to produce an index with smudged entries

I am trying to find out how native git handles the racy git problem. I read https://raw.github.com/git/git/master/Documentation/technical/racy-git.txt. But I cannot reproduce the behaviour described in this text.

I want to create an index which contains entries where the length of the file was set to 0 to mark the entry as "racily clean". As I understood the text you have to modify a file and execute 'git update-index <file>' so fast that in the end the files modification time is the same as the modification time of the file .git/index. That should be sufficient that when persisting the index during the 'git update-index' call git should detect that the files mod-time is younger than the index mod time and should mark this entry "racily clean" with a length of 0.

Here is the script with which I try to produce it but it always fails to create an index with a smudged entry. Any ideas? (Btw: I would assume that the first entry in the index is smduged when I find 4 zeros beginning at position 48. That's what I deduced from https://github.com/gitster/git/blob/master/Documentation/technical/index-format.txt)

#!/bin/bash

git init echo "initial" > foo

# wait for the next tick on the filesystem clock
touch foo
lastTouch=$(stat -c %Y foo)
while [ $lastTouch = $(stat -c %Y foo) ] ;do
  touch foo
done

git add foo

# modify 'foo' and update the index
# (hopefully before the filesystem clock has increased)
# repeat this step until the filesystem timer increased and
# print the index everytime
lastTouch=$(stat -c %Y foo)
while [ $lastTouch = $(stat -c %Y foo) ] ;do
  echo "modification #$n" > foo
  git update-index foo
  let "n += 1"
  echo "after attempt $n:"
  # dump 4 bytes of index beginning from pos 48.
  # That should be the length of the first entry
  od -j 48 -N 4 -x -A d .git/index
done

Christian Halstrick skrev 2011-09-30 17.33:

I guess that code is only likely to work if USE_NSEC is not set or the file system has only whole second resolution. It might be very hard to reproduce the situation since the likehood that a file AND the index has the same timestamp at the subsecond level is very small. Nasty thing to test :)

Is your file system one that does not have subsecond timestamp resolution? The nanosecond part of the timestamp(s) should be 0 (byte 24-27 for mtime for the first index entry).

Touch can set the timestamp to an explicit value, so you can use that instead of waiting for luck. Touch cannot set ctime, but you can make git ignore ctime by setting core.trustctime to false.

For testing the issue with nanosecond resolution you have to roll your own touch in C, perl or even Java.

-- robin