It's worth pointing out that even in the absense of races, you can
obviously screw things up if you really work at it, and *want* to. We
cannot guarantee that we see all file changes from the stat() information,
and we don't even save the whole stat info (ie we only save the low 32
bits).
The ctime check is there to help make it harder for people to play games
by setting the mtime back in time after having changed things, but we may
at some point be forced to remove it because it triggers with things like
beagle that use inode attributes to save indexing information (and thus
change ctime).
And different systems have different approaches to what happens when a
file gets modified through a writable mmap(). Exactly what is the mtime
going to be?
So I think git does a really good job at matching the stat() information,
and the suggested patch makes it even stricter, but I think we should not
even try to make it handle "malicious" changes. I bet you can work at
making it miss some update if you really *really* try.
And I think there is one known race: the index mtime itself is not
race-free. Remember: it may take more than a second to write the index
file! So I can imagine that if you can set it up so that you change the
file as the index is written out, and the index write is delayed
sufficiently, the racy timestamp logic can fail just because the timestamp
on the index file ends up being later.
This is more easily shown by doing a 'touch' on the index file afterwards,
of course.
And yes, we should have written the timestamp to the file itself, instead
of reading it from the filesystem.
Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
