>> I had thought about this. I hacked some code up where the index looks >> at the current system time when updating a cache entry to determine if >> the hash is racy. Is doing one time(NULL) call per file reasonable? >> I'm guessing it must be cheaper that a stat call. > > Hmm, sorry, could you elaborate how you would plan to use the return value > from time(2) per file? My bad, I was extremely unclear. I meant I had thought about not bothering to look at the index file timestamp (I'm not sure why, but I instinctively trust the system clock more!). I'm making the same assumptions, i.e. files are not touched while they're being indexed. I suppose with the way I'm doing things, you can touch a file right up to the point where the index wants to stat that particular file and maybe look at its contents, but not afterwards. (And this is pretty useless, because how are you going to know which file the index is up to?) I maintain a flag per file, and after computing its SHA1, I compare the mtime with the current system time. If it matches, then that means the hash can't be trusted (because of the race condition) and I set the flag. This way, I avoid examining the index timestamp. I call time(NULL) for each file out of laziness. I could cache the value somewhere the first time, but that means I'd have to pass around an extra argument to a whole bunch of functions, because of the way I've written my code. But I don't think it's much of a drawback, because I stat() each file anyway. Actually, what Linus describes would be desirable in some sense. If the index mtime timestamp were always later than the time you performed the indexing (and accurate) because it always took a long time, assuming no one messes with files while you're indexing, there would be no race condition to worry about. -Ben -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
