File download via Zipdownloader tool creates damaged archives?
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 1.1k
- Forks
- 564
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 29
Description
What steps does it take to reproduce the issue?
- go to any dataset using the standalone zipper tool (e.g. https://doi.org/10.11588/DATA/N1T5T8)
- press button "access dataset" -> Download ZIP
- try to extract the files in the ZIP
What happens?
The extraction of files from the zip fails:
unzip -v dataverse_files.zip
Archive: dataverse_files.zip
warning [dataverse_files.zip]: 10342 extra bytes at beginning or within zipfile (attempting to process anyway)
| Length | Method | Size | Cmpr | Date | Time | CRC-32 | Name |
|---|---|---|---|---|---|---|---|
| 10485117 | Defl:N | 10400432 | 1% | 2025-02-03 | 16:26 | deeb27c3 | FUQ.pdf |
| 21014 | Defl:N | 18286 | 13% | 2025-02-03 | 16:26 | df8d22ca | Derived_requirements.docx |
| ... |
Apparently, each file has a bad zipfile offset.
We tested the multi file download for different datasets, on different machines, checked the Payara and Apache logs but found nothing obvious there. The single file download (= not using the zipper tool) works perfectly.
To whom does it occur (all users, curators, superusers)?
All users.
Which version of Dataverse are you using?
v 6.5
Any related open or closed issues to this bug report?
I found none.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the standalone zipper download from the linked dataset and checking the resulting archive with unzip -v. Trace the multi-file download path used by the Zipdownloader tool, contrasting it with the working single-file download. Done means ZIP archives extract without offset warnings across multiple datasets, with regression coverage for the affected path.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100