Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a zip archive of ~250Mb located on an Apache HTTP server. Several users have complained of a "corrupt zip folder" after downloading the file directly from the website (albeit the site is built on Drupal but it is using the public download method so it should be a direct download)

The error message when they try to open it in Windows is:

The compressed (zip) folder is invalid or corrupted

I have tried this myself on Windows XP and using both Firefox 14 and IE8. Sometimes it downloads and opens correctly, sometimes I get the error.

Another user is on Windows 7 and using Internet Explorer and has got this message after several download attempts.

When I download via FTP using Filezilla I can open the zip file without errors.

As FTP and HTTP download works at times, then I assume the file on the server is not corrupted but something happens during download and re-uploading the file would not fix anything (and I have tried this).

I created the zip file using IZArc but I am not so sure the method of creation is relevant in this case as it sometimes works.

  1. What causes the above error messages?
  2. Why does it happen some of the time and not all of the time?
  3. What could I do to ensure zip files open without any errors in future?
share|improve this question
The answer to all your questions is that the file is corrupt. Do they get this error when using actual software design to extract a .zip file? –  Ramhound Aug 20 '12 at 12:02
Check to make sure that either clients are getting a Content-Length header when they download the file or the transfer encoding is chunked. Otherwise, truncation is possible. –  David Schwartz Aug 20 '12 at 12:26
@Ramhound, that's more the question really than the answer. The question is: What causes the corruption in cases where it is corrupt sometimes and not others (and for different people on different network connections/software set-ups). Why should it be so inconsistent assuming the original file is OK? –  authentictech Aug 20 '12 at 12:40
@DavidSchwartz, that sounds promising. Can you clarify how one would go about checking that clients are getting a Content-Length header? Thanks. –  authentictech Aug 20 '12 at 12:54
@DavidSchwartz I used Fiddler to check the response headers and the Content-Length header is sent with value that is the size of the file so it looks like all is well there. –  authentictech Aug 21 '12 at 17:46
add comment

3 Answers

up vote 3 down vote accepted

What causes the above error messages?

The download is probably corrupted or truncated (incomplete). Check if the downloaded filesize is same as the size on the server.

Why does it happen some of the time and not all of the time?

The download could be truncated due to the connection being dropped, which is something random - it might happen and might not happen. If your connection quality is better, it'll probably be less likely to occur.

What could I do to ensure zip files open without any errors in future?

Provide checksums for all your downloads, and get your users to verify them. You can't really avoid network issues, however. You may wish to speak to your host.

share|improve this answer
That is probably the most helpful and complete answer, thanks. I will look into what you say and most likely come back and mark this as the answer. In the meantime, why do you think it would be so inconsistent given different users on different connections and software set-ups? Assuming the original file is OK (which it must be if it sometimes opens) I don't see why I should particularly be having this problem as often as I do with this file. I have downloaded a lot of zips in my life and only occasionally have corrupt files, but not as often as in this instance. Thanks. –  authentictech Aug 20 '12 at 12:46
Particularly, what could I ask my host in order to point them in the right direction to a possible solution to the problem? What might be going wrong at their end? Thanks. –  authentictech Aug 20 '12 at 12:55
Is it only with a particular zipfile? Have you tested with zipfiles (or other files) of smaller or larger sizes? It could be large size providing more time for a connection drop, which is why you only see this problem with this file. Also, could it be the PHP script serving the download getting timed out (since you mentioned Drupal)? If not, you might ask your host to check for any connection problems on their end, mentioning this problem. –  angelsl Aug 20 '12 at 13:00
I haven't tested with others but will try. It makes sense that larger files can have more connection drop issues. I and most users are on stable broadband Net connections though (doesn't TCP/IP handle this problem?). I am linking directly to the file so I assume Drupal doesn't get involved in that (although it can if you change to private download method). In this case, the users are non-technical and wouldn't cope with checking checksums. I have re-created the zip using Windows rather than 3rd party software to see if that makes a difference. Thanks for your help. –  authentictech Aug 20 '12 at 13:52
The host isn't providing any help other than saying that they can download the file OK at their end so while I don't think I know exactly why this has been happening so frequently I am going to mark this as the answer as it will probably apply in most cases. Thanks. –  authentictech Aug 21 '12 at 17:50
show 1 more comment

One thing you can do to troubleshoot what's going on is to use MD5 or SHA-1 hashes of that zip file. I assume you have the original zip available to you offline.

Using Cygwin, you can compute a SHA-1 or MD5 hash of your zip file then publish the result. Hashes are really cool because they can be used to verify to the bit level that one file is exactly the same as another. For example: The hash for a file containing "0123456789" is 3749f52bb326ae96782b42dc0a97b4c1. The hash for a file containing "1123456789" is b0b7fa225796be83e7fea1345c13d3dd.

If I remember my ASCII right, there's only a single bit difference between the two strings but as you can see there's a huge difference in the resulting hashes. Publishing an MD5 or SHA-1 hash is a very common thing to do in the software development world since it's a very good way to ensure that you're files aren't corrupted. After publishing the MD5/SHA-1 hash, you could have your customers take a hash of the zip to see if it's actually corrupted or not.

There are plenty of utilities out there for Windows, Linux and Mac that will generate MD5 and SHA-1 hashes. I use Cygwin because it's free.

share|improve this answer
This makes sense in many situations. I am dealing with very non-technical users, though, who would not cope with hash checking, but that's good advice generally. Thanks. –  authentictech Aug 20 '12 at 13:56
add comment

If file on client side have correct size, this situation might be caused by faulty memory on client PC or faulty network equipment in between. Often random bit-switching is not especially apparent in many applications, but when it comes to checksums that are used to check archive integrity, every bit matter and those errors become obvious.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.