Does this only affect workspace downloads, or also artifact downloads?

What's the transfer speed?

Seems for me, it affects both sub-directories as well as the entire workspace so long as the file size is > 20.6MB's. Individual artifacts appear to download fine.

I originally noticed this trying to download a sub-dir of the workspace, which should be ~110MB's in zip form, but it always truncates at 20.6MB's and the zip is corrupted (cannot be unzipped).

Seems like it transfers are normal speeds, either 5-10Mbps+ on the local lan (assuming it's not faster due to overhead of creating the zip) and about 1Mbps over the net.

Hi all,

I seem to have the same problem. I'm working on Jenkins 1.581 running on Tomcat 7 on MacOS 10.8.5.

Zipping a subdirectory within the workspace works fine, whereas zipping and download the entire workspace does not. Zipping the entire workspace even creates a smaller zip file (e.g. 80MB) than the zip creation of a subdirectory (115MB)!

Any idea?

It would be great if you could provide a minimal, reproducible test case, such as a shell script build step that generates a bunch of files that result in this problem when downloaded.

Hi all,
I am experiencing this same issue with Jenkins 1.643 running on Linux Debian 8 and the same symptoms as specified by Stefan, the jenkins link "all files in zip" provides a corrupted zip file, our corporate network could be somewhat slow but I don't think that could be related.

Steps to reproduce:

1. Create a new freestyle job "test-job", Linux or OS X should be ok
2. Add a shell script step with the following content

   for i in {1..1000}
   do
       dd if=/dev/zero of="ABC1MB-${i}.bin" bs=1024 count=0 seek=1024
   done
   
   mkdir -p a/b/c/
   echo "text" > a/b/c/1
   pushd a
   ln -s b/c/1 2
   popd
   
   mkdir -p d/e/f
   pushd d
   ln -s e/f/1 2
   popd
   

3. Run a build to generate workspace
4. Download workspace using "(all files in zip)" link in workspace browser
5. Try to unzip

Expected results:

• Unzipping will succeed
• Unzipped directory mimics actual workspace, including symlinks

Actual result:

• Invalid archive with error:

  # Note: unzip on OS X
  $ unzip test-job.zip
  Archive:  test-job.zip
    End-of-central-directory signature not found.  Either this file is not
    a zipfile, or it constitutes one disk of a multi-part archive.  In the
    latter case the central directory and zipfile comment will be found on
    the last disk(s) of this archive.
  unzip:  cannot find zipfile directory in one of test-job.zip or
          test-job.zip.zip, and cannot find test-job.zip.ZIP, period.
  # Note: ditto on OS X
  $ ditto -x -k test-job.zip .
  ditto: test-job/d/2: No such file or directory
  ditto: Couldn't read pkzip signature.
  

Problems with current state:

• "Broken" symlinks, or symlinks to files that do not exist, apparently cause termination of zip file creation, thereby generating an invalid zip
• "Working" symlinks, or symlinks to files that do exist, add duplicate copies of files
• Recursive symlinks probably cause problems too