In [this build](https://gitlab.haskell.org/ghc/ghc/-/jobs/102219) (`x86_64-linux-deb9-debug` job) the `hDuplicateTo001` test failed with: ``` Wrong exit code for hDuplicateTo001(threaded2)(expected 0 , actual 1 ) Stderr ( hDuplicateTo001 ): hDuplicateTo001: tmp: hDuplicateTo: resource busy (Device or resource busy) *** unexpected failure for hDuplicateTo001(threaded2) ``` This is the only time I have seen this failure. I believe `hDuplicateTo` ultimately calls `dup2` (see `GHC.IO.Handle.dupHandleTo`). The manpage for `dup2` claims that this error might be returned if: ``` EBUSY (Linux only) This may be returned by dup2() or dup3() during a race condition with open(2) and dup(). ``` In other words, we asked the kernel to make the file descriptor `dest` a duplicate of handle `src`, but while this operation was underway another thread allocated `dest`. It's rather unclear what to do here. I can see how this would happen but it's quite unclear what we can do about this. It seems to me like it is nearly impossible to use this operation in the threaded runtime, given how little control you have over when and how fds are allocated. I'm going to disable this test in the threaded way.