New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Work around non-deterministic failure of uncompress on Windows #21599
Comments
comment:2
And then some bikeshedding:
And of course this is an ugly hack, but that's not your fault. |
comment:3
D'oh! Agreed with all of the above. |
comment:4
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. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:7
Two minor things again:
|
comment:8
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 :) |
Branch pushed to git repo; I updated commit sha1. New commits:
|
New commits:
|
Reviewer: Jeroen Demeyer |
Changed branch from u/embray/bug/uncompress-windows to |
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.
Component: porting: Cygwin
Author: Erik Bray
Branch/Commit:
69830cd
Reviewer: Jeroen Demeyer
Issue created by migration from https://trac.sagemath.org/ticket/21599
The text was updated successfully, but these errors were encountered: