throw 'unexpected EOF' about fflate HOT 10 CLOSED

$ unzip test-0001.zip 
Archive:  test-0001.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-0001.zip or
        test-0001.zip.zip, and cannot find test-0001.zip.ZIP, period.

Even the CLI fails to unzip it. However, you are correct that Windows can unzip this natively, and so can 7zip, so I'll look into the issue and see what the problem is.

from fflate.

Can you double check the total file size of test-0001.zip is 655042854 bytes?

~/: unzip test-0001.zip 
Archive:  test-0001.zip
  inflating: test-0001        

The actual error is bit positions getting larger than 32 bit so JavaScript >>> won't work.

from fflate.

That's true, I should mention the limit of 512 MB on synchronous unzip. However, streaming inflate does work on larger files, so I'll see if that works for this.

Yes, you were right, that was a PEBKAC, this ZIP is valid. I'll fix this by adding support for streaming when files become too large.

from fflate.

It shouldn't fail with a cryptic error for synchronous. Why not fix it to work via (pos / 8) >> 0?

from fflate.

I decided against that because I was worried that the division operator followed by a bit shift would be much more expensive than a single bit shift, but as it turns out what you suggested isn't any slower. I was thinking of (and just now finished) making the synchronous operation default to synchronous streaming when files were too large, but I suppose that's not as performant as your suggestion.

from fflate.

@lutzroeder I've finished making changes to support the full 4GB maximum supported by Uint8Array itself. Thanks for the suggestions, help, and debuggable examples ❤️ I'll be pushing an update shortly.

from fflate.

Check v0.4.4 on the NPM registry. Thanks for the bug report!

from fflate.

Hey @lutzroeder, I noticed you added a subsection of fflate into netron. I understand that depending upon the NPM package would be difficult, since netron's build process doesn't allow for tree shaking, but I would appreciate if you could still attribute the project in the source code or README. Thanks for your interest!

from fflate.

Reverted the change. The main fork is a rewrite from scratch using the reverse mapping algorithm from UZIP.js and has a UZIP.js reference added to the source.

from fflate.

The algorithm is actually from SO, you may want to cite that instead. Nothing special about the change except shift down a bit, since they're all 15 bit integers I managed to find a way to optimize further. Either way, hope your rewrite works well.

from fflate.