Re: git bugs

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 10 Jun 2008, Ben Lynn wrote:
>
> Nice! I believe I can prove there are no races now.

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