Fixing a corrupt or unreadable zip
Angio and other large studies are the uploads most likely to produce a zip that will not open. This page explains how to tell which problem you have, because the fixes are genuinely different — and one of them is "there is nothing to repair, re-export".
Most of the time you will not need this page: the portal now checks the archive in your browser before the upload starts, and repairs damaged archives automatically on the server. This is for the cases it cannot fix for you.
Start here: which problem do you have?
The portal names the problem for you. Match the message you saw against this table.
| What the portal said | What it means | Can it be repaired? |
|---|---|---|
| This file has no ZIP structure in it at all | The file was never a zip. Most often one piece of a split archive, or an export that never finished. | No — re-export |
| This is one volume of a split archive | Your zip tool split the study into parts. Only the last part holds the index. | No — recombine or re-export |
| This file is not a ZIP archive (7-Zip, RAR, etc.) | A different archive format was given a .zip name. | No — re-export as a real zip |
| This archive is password-protected | The archive is encrypted. | No — re-export without a password |
| Missing the index it keeps at the very end | Zipping or copying stopped early. The images are usually still in there. | Yes, automatically — see what the portal repairs |
| QC failed on Archive Integrity after upload | The archive was repaired, but some images could not be recovered. | Partly — see below |
If you take one thing from this page: keep each archive under about 2 GB and upload one timepoint per zip. Nearly every failure below either disappears or becomes trivially recoverable at that size. See Avoiding the problem.
What the portal repairs for you
A zip keeps an index of its contents in the last few bytes of the file. Zip readers use that index to find anything at all, so if it is missing or damaged the archive will not open — even when every image inside it is perfectly intact. This is the single most common way a large study "goes corrupt", and it is fully recoverable.
When the portal sees this, it rebuilds the index by walking the archive from the front, checks every image against its own checksum, and processes everything that survives. The archive you uploaded is never modified — the rebuilt copy is stored separately.
You will then see one of two results on the upload:
- A warning, and the upload processes normally. Everything was recovered. Nothing further to do.
QC FAILEDon Archive Integrity. Some images could not be recovered, or the index was destroyed so completely that we cannot prove nothing was lost. The QC entry lists the files that failed. Re-upload the study to be safe — an upload that is quietly missing series is worse than one that fails loudly.
The archive is one piece of a split set
Zip tools offer to split a large archive into volumes, producing files like:
Angio.z01 Angio.z02 Angio.z03 Angio.zip
or, with 7-Zip's scheme:
Angio.zip.001 Angio.zip.002 Angio.zip.003
Only the final .zip carries the index. The .z01, .z02 … volumes are raw data
with no index and no recognisable header, so no tool on earth can open one on its own —
it is not damaged, it is simply a fragment.
(WinZip,
WinRAR)
This is worth checking first for angio studies, because it is the failure that looks most like catastrophic corruption: a multi-gigabyte file with no zip structure anywhere in it.
How to fix it
- Look in the folder the archive came from for sibling files with
.z01/.zip.001style names. - If they are all there, put every part in one folder with their original names and open
the final
.zip(not the.z01). Extract it, then re-zip as a single archive. - If parts are missing, they cannot be reconstructed — re-export from the PACS.
- Best: re-export without splitting, or split the study by timepoint or series into separate complete zips and upload them as separate rows. The portal handles many archives far better than one enormous one.
The archive was never a zip
If the portal reports no zip structure anywhere in the file, the bytes are not a damaged archive — they were never a zip container. There is no index to rebuild and no file headers to walk, so repair tools have nothing to work from.
Realistic causes, in the order worth checking:
- It is a middle volume of a split set (see above). By far the most common.
- The export never finished. The file was copied or written while the PACS export was still running, so you have a fragment that starts nowhere in particular.
- The file is an encrypted or proprietary container produced by the exporting workstation and renamed.
How to fix it: re-export the study from the PACS, wait for the export to report that it is complete, confirm the file size looks right, and zip it locally on your own machine.
The file is a different kind of archive
7-Zip (.7z), RAR (.rar), and gzip/tar (.tar.gz) archives are not zips, and renaming
one to .zip does not convert it. The portal detects this and tells you which format it
actually found.
How to fix it: open it with the tool that created it, extract the DICOM files, and
re-compress as a genuine .zip. On Windows, right-click the folder → Send to →
Compressed (zipped) folder. On macOS, right-click → Compress.
The archive is password-protected
The portal cannot open encrypted archives — there is nowhere to enter a password, and we would not want one stored. Re-create the archive without encryption. Imaging is protected in transit and at rest by the platform itself, so archive passwords add nothing.
The archive was zipped before the export finished
The classic silent corruption: the export is still writing files when the folder gets zipped, so the archive ends mid-image.
How to fix it
- Wait for the PACS or workstation to report the export as finished.
- Confirm the file count in the exported folder matches what you expect.
- Copy the folder to your own machine first if it came from a network share, CD, or USB drive — zipping directly from removable or network media is a frequent cause.
- Zip the local copy and upload that.
The study is near or above 4 GB
Zip stores file positions in four bytes, which caps a plain zip at 4,294,967,295 bytes. The ZIP64 extension lifts that limit, but not every tool implements it correctly: some produce archives that quietly break past the boundary, and others write the multi-volume fields incorrectly so that strict readers reject an otherwise valid file. (ZIP64 explained, a real-world example of malformed ZIP64 output, Info-ZIP's own limits documentation)
Angio studies sit right on this boundary, which is why they fail more often than anything else.
How to fix it: split the study by timepoint or by series into separate complete archives, each comfortably under about 2 GB, and upload them as separate rows. Do not use your zip tool's "split into volumes" option — that creates the multi-volume problem described above. You want several independent, complete zips.
Repairing a zip yourself
If you want to try recovering an archive before re-exporting, these are worth attempting in this order. All of them work by ignoring the damaged index and reading the archive from the front.
1. zip -FF — rebuild the index (macOS and Linux; the most likely to work)
zip -FF broken.zip --out fixed.zip
2. jar xf — extract without the index at all (anywhere Java is installed)
jar reads the archive sequentially and ignores the index entirely, so it often succeeds
where unzip refuses to start.
mkdir recovered && cd recovered && jar xf ../broken.zip
3. 7-Zip — attempt recovery
7z x broken.zip -orecovered
In the 7-Zip GUI, open the archive and extract with Keep broken files enabled.
If the portal told you the file has no ZIP structure in it at all, every tool above will fail, and so will any "zip repair" product you find online. There is no index to rebuild and no headers to walk. Re-exporting is the only path — please do not spend money on recovery software for this case.
After any repair, check what you actually got back before uploading: open the fixed archive and confirm the number of images is what you expect. A repair that silently recovers half a study is worse than one that fails.
Avoiding the problem
- Keep each archive under about 2 GB. This single habit prevents most of this page.
- One timepoint per zip, as described in Uploading Imaging.
- Never use "split into volumes." Make several complete zips instead.
- Copy from network shares, CDs, and USB drives to your own machine before zipping.
- Let the export finish, and check the file count, before you compress anything.
- Wait for the browser scan to finish after attaching a file. It reads the archive's index and will refuse a file that cannot be processed — before you spend an hour uploading it.
Still stuck?
Contact us with the upload ID (use Copy upload ID on the Uploads table), the subject ID, the site, and roughly when you uploaded. If the upload reached processing, we can see exactly which file failed and why.