Re: comparing file contents in is_exact_match?

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 17, 2006, 17:10 UTC
Message-ID: <Pine.LNX.4.63.0607171907080.29667@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <17595.48003.145000.414361@lapjr.intranet.kiel.bmiag.de>

Hi,

On Mon, 17 Jul 2006, Juergen Ruehle wrote:

Show 15 quoted lines

> Johannes Schindelin writes:
>  > > > It is not Cygwin really. It's windows. You can't rename or delete an
>  > > > open or mmapped file in that thing.
>  > > 
>  > > And GIT's workaround is to read the whole file into memory and close
>  > > it after that?  Uh-oh.
>  > 
>  > If you have a better idea (which does not make git source code ugly), go 
>  > ahead, write a patch.
> 
> On several boxes I've tested the mmap code passes the tests on NTFS.
> 
> It is usable for my simple work even on FAT32 with an unlink before
> the rename in lockfile.c, but that probably breaks in more involved
> scenarios.

In my not-so-simple tests, it failed. Reproducibly. If I am not mistaken, your test just does not hit the problem, namely fork()ing after rename()ing a mmap()ed file.

Now, with the diff changes a few months ago, there are way less fork()s in the code, that might be one reason you do not hit the wall, but I could imagine that a "git-read-tree -m -u" still has problems. Note: I did not test what I just said, but I _did_ test that there are problems with mmap() when you fork() with the map in use.

Ciao, Dscho