Downloading a ZIP archive of the workspace from a project that was built on a slave appears to be broken since Hudson 1.378 (found by bisection between 1.365 and 1.406-SNAPSHOT). It worked and still works when the project was built on the master, so no remoting takes place.

How to reproduce:

1. Set up a free-style project that just creates a few files in the workspace, such as:

   env > env.txt
   ls -la > ls-la.txt
   dd if=/dev/urandom of=random.bin bs=512 count=2048
   

2. Restrict this project to run on a slave (connected via SSH in my case).
3. Run this project.
4. Using the "(all files in zip)" link, download the workspace and verify the downloaded Zip archive. With 1.377 and before, you can run the download and verification step in a loop from the command line for 100 times in a row without error. Since 1.378, it will usually fail at the second attempt and will, on first glance at the hexdump, look like a correct but truncated Zip archive. The script that I used for testing is this:

   $ cat test.sh 
   i=0
   while [ $i -lt 100 ]; do
           i=`expr $i + 1`
           echo $i
           wget -q -O test.zip 'http://localhost/jenkins/job/test/ws/*zip*/test.zip' && \
           unzip -l test.zip > /dev/null || exit $?
   done
   exit 0
   

Known workaround:

• Run the job on the Jenkins master. (This isn't an option in our setup.)

Possibly related issues:

The changelog of 1.378 mentions JENKINS-5977 "Improving the master/slave communication to avoid pipe clogging problem." and I suspect that this change introduced the problem. A later changelog entry for 1.397 mentions that it fixed "a master/slave communication problem since 1.378" (JENKINS-7745). However, using the steps described above I can still reproduce at least this issue, even in the current version 1.404 and the latest snapshot.

As suggested in comments of other issues touching on the field of master/slave communication, it would seem reasonable to assume that this issue could be caused by a missing flush operation on an output stream, or something to that effect. Another possibility, however likely, might be the suspected thread concurrency problem noted in remoting/src/main/java/hudson/remoting/PipeWindow.java, where it also mentions the issues JENKINS-7745 or JENKINS-7581.