Aborting a build while artifacts are being copied through the remoting channel results in a FAILED status instead of an ABORTED status.

After discussing this with jglick, he provided me hints on how to fix that, I quote him:

FastPipedInputStream.read could be made to throw InterruptedIOException rather than a generic IOException. Then FilePath.readFromTar could rethrow either InterruptedIOException or another InterruptedException as an InterruptedException with details about the tar entry (the signatures of its callers allow InterruptedException). Proving this all works in a test could be tricky, since you would need to have a special remoting channel that deliberately hangs at a specific point (the code in the mock-slave plugin could perhaps be ported to a test utility).

Stack trace on build log:

java.io.IOException: java.io.IOException: Failed to extract /..... of 193 files
at hudson.FilePath.readFromTar(FilePath.java:2286)
at hudson.FilePath.copyRecursiveTo(FilePath.java:2197)
at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61)
at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:218)
...

Caused by: java.io.IOException: java.lang.InterruptedException
at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:177)
at hudson.util.HeadBufferingStream.read(HeadBufferingStream.java:61)
...
Caused by: java.util.concurrent.ExecutionException: java.io.IOException: Pipe is already closed
at hudson.remoting.Channel$3.adapt(Channel.java:784)
at hudson.remoting.Channel$3.adapt(Channel.java:779)