git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git bugs

From
Ben Lynn <benlynn@gmail.com>
Date
Jun 11, 2008, 00:02 UTC
Message-ID
<832adb090806101702l79aba80cvba1eaab029e9ecd5@mail.gmail.com>
In-Reply-To
<7v1w34dfn3.fsf@gitster.siamese.dyndns.org>
Show 7 quoted lines
>> 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
Previous: Junio C HamanoNext: Junio C Hamano
Message 8 of 35 in “git bugs”
  1. Ben LynnJun 10, 2008
  2. Daniel BarkalowJun 10, 2008
  3. Linus TorvaldsJun 10, 2008
  4. Ben LynnJun 10, 2008
  5. Linus TorvaldsJun 10, 2008
  6. Ben LynnJun 10, 2008
  7. Junio C HamanoJun 10, 2008
  8. Ben LynnJun 11, 2008
  9. Junio C HamanoJun 11, 2008
  10. Ben LynnJun 11, 2008
  11. Ben LynnJun 11, 2008
  12. Stephen R. van den BergJun 11, 2008
  13. Ben LynnJun 12, 2008
  14. Linus TorvaldsJun 11, 2008
  15. Ben LynnJun 11, 2008
  16. Linus TorvaldsJun 11, 2008
  17. Ben LynnJun 11, 2008
  18. Linus TorvaldsJun 11, 2008
  19. Ben LynnJun 11, 2008
  20. Ben LynnJun 11, 2008
  21. Linus TorvaldsJun 11, 2008
  22. Ben LynnJun 11, 2008
  23. Linus TorvaldsJun 11, 2008
  24. Ben LynnJun 11, 2008
  25. Linus TorvaldsJun 11, 2008
  26. Ben LynnJun 11, 2008
  27. Junio C HamanoJun 11, 2008
  28. Linus TorvaldsJun 11, 2008
  29. Junio C HamanoJun 12, 2008
  30. Jeff KingJun 13, 2008
  31. Junio C HamanoJun 13, 2008
  32. Jeff KingJun 14, 2008
  33. Shawn O. PearceJun 12, 2008
  34. Ben LynnJun 12, 2008
  35. Johannes SchindelinJun 12, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.