Corruption issue from filesystem exception.

[Martin Geisler]

Sune Foldager <cryo at cyanite.org> writes:

> I have come up with a reproduction scenario for this problem.
>
> I made a program which watches all newly created files in a
> directory and opens all of them (with full share modes, like a virus
> scanner likely would) for 1000ms (just to be sure). Since I lack
> experience in Windows C++ as well as Windows non-.NET-apis in
> general, it's written in C#.net. The source code and an executable
> are available here:
>
> http://cyanite.org/snitch/
>
> In one command window, start the program like this: filesnitch
> /path/ to/repo/.hg In another, goto that repo and do a few hg up -r
> <some rev>. The problem should occur pretty often (every 2-3 times
> on my laptop).
>
> As theorized earlier, the problem occurs with the tmpxxx files; the
> dirstate, .dirstate-xxx, wlock and other files are also kept open,
> but this is not a problem since they are not in the way of a
> rename. The proposed patch, replacing mkstemp with mktemp removes
> the problem since the tmpxxx file is never created (until something
> is renamed into it, but that doesn't matter at that point).

Based on your testing and explainations I definitely think we should
take your fix. Could a crew member with Windows please test this too?

But as you say it is not so nice to begin using a deprecated command,
so could you put a simplified version of mktemp into mercurial.util,
maybe even something as simple as this:

  def mktemp(dir):
    name = dir
    while os.path.exists(name):
      name = os.path.join(dir, "tmp=%d" % random.randint(0, 1000000))
    return name

With a prominent warning in the docstring about the race condition I
would fine with this.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.