Steps to reproduce

1. Create a plan with a script task with contents similar to:

   ln -sf /dev/stderr my-artifact
   

2. Configure the job to save "my-artifact" as an artifact.
3. Run the plan on a Linux agent.

Note that /dev/stderr can be replaced by any named pipe (e.g. mkfifo my-artifact).

Expected result

The build should finish, either

• as a green build with "my-artifact" missing or saved as a 0 byte file, or
• as a red build with an error about being unable to save "my-artifact".

Actual result

Build hangs forever on the log line "Publishing an artifact: my-artifact" until manually stopped.

Once manually stopped, the build goes grey with logs similar to the following:

17-Oct-2017 06:58:57 	com.atlassian.bamboo.build.artifact.S3ArtifactHandler: Unexpected exception
17-Oct-2017 06:58:57 	Unable to publish artifact [test link]: Unable to publish artifact Job artifact: [my-artifact], pattern: [my-artifact] for MYPROJ-MYPLAN-JOB1-123 via com.atlassian.bamboo.build.artifact.S3ArtifactHandler@3e641fa3

Notes

This is disruptive because:

• a hung build ties up an agent, reducing build capacity until noticed and corrected by a human,
• a named pipe could be present inside a directory, and if the directory is being saved as an artifact, the same result will occur (perhaps a more likely scenario than someone actually trying to save a named pipe as an artifact).

It happens both with the S3 and server local artifact handlers. However, in my testing the build could not even be stopped manually when using the server local artifact handler.