Work around non-deterministic failure of uncompress on Windows

[embray]

I've noticed sometimes while building on Windows / Cygwin (though this isn't cygwin-specific) some package builds can fail randomly, usually during the uncompress step. Re-rerunning the build a second time always succeeds.

This happened one time recently and I realized there was a Python traceback leading back to the os.rename call wrapped by the attached patch.

This can happen because if any background process happens to have any file in the tree open, even briefly, the renaming the entire directory can fail. So this is especially likely to happen when unpacking source tarballs containing a large number of files.

There may be other points where this can happen, and I'll apply the same workaround if/when I encounter them.

[jdemeyer]

1. If the final try failed, the exception should be raised!

And then some bikeshedding:

2. The usual way to handle such things is an exponential sleep. So I would suggest a delay *= 2 in the while loop.

3. I would also prefer to see tries instead of retries. I find it easier to understand "3 tries" instead of "1 try and 2 retries". And you know that, because you found it necessary to explain in the docstring.

And of course this is an ugly hack, but that's not your fault.

[embray]

D'oh! Agreed with all of the above.

[embray]

And yes it's an ugly hack but not an uncommon one. I feel like I've done this a dozen other times for Windows support in various places.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​822f0d1

Re-raise the exception if it is raised on the final try.

[jdemeyer]

Two minor things again:

1. Replace func() by return func(). This way, you support functions which return something. It also means that you can remove the else: break.

2. The condition while tries > 0: is now always true. So for simplicity, I would prefer to see while True there. That makes it clear that the loop can never be exited normally. By the way, this is a good example of code which would be cleaner with a goto statement.

[embray]

Agreed again on all of the above.

The only people who think gotos are evil have never written non-trivial C code and haven't read/don't understand the context of Dijkstra's essay :)

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​69830cd

Additional minor cleanup:

[embray]

New commits:

​69830cd

Additional minor cleanup: