Re: git bugs

On Tue, 10 Jun 2008, Ben Lynn wrote:

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