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

Re: comparing file contents in is_exact_match?

From
YLYakov Lerner <iler.ml@gmail.com>
Date
Jul 17, 2006, 12:11 UTC
Message-ID
<f36b08ee0607170511u97b1c35s546a47bf8035eb70@mail.gmail.com>
In-Reply-To
<20060716223607.GA6023@steel.home>
Florian Weimer wrote:
> And GIT's workaround is to read the whole file into memory and close
> it after that?  Uh-oh.
On 7/16/06, Alex Riesen <fork0@t-online.de> wrote:
Show 9 quoted lines
> Yakov Lerner, Sun, Jul 16, 2006 17:03:49 +0200:
> > Cygwin has mmap. But cygwin's mmap() not good enough for git.
> > What happens is that git does rename() when target file has active mmap().
> > In cygwin, this makes rename() to fail. This is what makes cygwin's
> > mmap unusable for git. (BTW for read-only git access, mmap() will work
> > on cygwin, for what I saw. But attempts to modify index will break).
>
> It is not Cygwin really. It's windows. You can't rename or delete an
> open or mmapped file in that thing.

We have right to expect cygwin to do some effort to emulate the unix mmap() semantics on top of different semantics of windows memory-mapped files. Why doesn't cygwin do some effort to detect active mmap()s on the file before rename and do something like (1) unmap (2) rename the target to temp name (3) remap. (4) take care of temp file cleanup ? Probably too messy even if possible. Is it reasonable to expect git to do this mess ? It probably belongs to the generic cygwin layer anyway.

I did try another kind of workaround, in which I unmapped the target file before rename. But it didn't work in all situations and was too intrusive to the git-apply logic. Didn't work.

Regarding the existing workaround (NO_MMAP), well, cygwin is not exactly a speed champion in many areas. I didn't really notice speed loss with NO_MMAP, maybe because cygwin loses time here and there anyway ?

Yakov
Previous: Yakov Lerner
Message 32 of 32 in “comparing file contents in is_exact_match?”
  1. Martin WaitzJul 6, 2006
  2. Junio C HamanoJul 6, 2006
  3. Martin WaitzJul 6, 2006
  4. Junio C HamanoJul 6, 2006
  5. Martin WaitzJul 6, 2006
  6. Martin WaitzJul 6, 2006
  7. Florian WeimerJul 7, 2006
  8. Johannes SchindelinJul 8, 2006
  9. Florian WeimerJul 16, 2006
  10. Johannes SchindelinJul 16, 2006
  11. Yakov LernerJul 16, 2006
  12. Alex RiesenJul 16, 2006
  13. Florian WeimerJul 17, 2006
  14. Johannes SchindelinJul 17, 2006
  15. Linus TorvaldsJul 17, 2006
  16. Johannes SchindelinJul 17, 2006
  17. Linus TorvaldsJul 17, 2006
  18. Martin WaitzJul 17, 2006
  19. Alex RiesenJul 17, 2006
  20. Geert BoschJul 17, 2006
  21. Linus TorvaldsJul 17, 2006
  22. Yakov LernerJul 18, 2006
  23. Johannes SchindelinJul 18, 2006
  24. Linus TorvaldsJul 18, 2006
  25. Alex RiesenJul 18, 2006
  26. Juergen RuehleJul 17, 2006
  27. Johannes SchindelinJul 17, 2006
  28. Juergen RuehleJul 17, 2006
  29. Yakov LernerJul 17, 2006
  30. Juergen RuehleJul 17, 2006
  31. Yakov LernerJul 18, 2006
  32. Yakov LernerJul 17, 2006

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.