Skip to content

Reporting correct compressed/uncompressed file sizes for zip64#654

Closed
ls-urs-keller wants to merge 1 commit into
Stuk:masterfrom
ls-urs-keller:master
Closed

Reporting correct compressed/uncompressed file sizes for zip64#654
ls-urs-keller wants to merge 1 commit into
Stuk:masterfrom
ls-urs-keller:master

Conversation

@ls-urs-keller

Copy link
Copy Markdown

I'm stream-uncompressing files around 1.6GB compressed, 11 GB uncompressed.
The file size is incorrectly read from zip64 file entry.

Everything works fine until at the very end when reading the stream it compares uncompressed size with the size actually read and throws an exception.

The left shift operator << seems to be the culprit e.g.:
10<<8<<8<<8<<8 = 0
whereas
10256256256256 = 42949672960

@JMS-1

JMS-1 commented Sep 13, 2021

Copy link
Copy Markdown

I would suggest to fix readInt (with * 256) instead of introducing a new function readLong. JavaScript makes no difference at all (as far as I understand there is no integral number representation).

And I would REALLY like this push request to be merged into the package! Actually ist starts crashing at 2GB! See #777. Although I start wondering if jszip is still maintained at all.

@ls-urs-keller

Copy link
Copy Markdown
Author

Closing in favor of #791

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants