how to produce an index with smudged entries

how to produce an index with smudged entries

[Christian Halstrick]

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

Re: how to produce an index with smudged entries

[Robin Rosenberg]

Christian Halstrick skrev 2011-09-30 17.33:
> 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 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