nils måsén

The Data Descriptor is part of the zip format that your corrupted file is missing (see: [appnote:4.3.8](https://p1k.se/appnote.md#s438-file-data)). SharpZipLib probably could still read the file, but not using the streaming API...

A zip file is not simply a deflate-compressed file, but an archiving format with file tables etc. The individual files inside the archive _**may**_ be deflated, but you need to...

Okay, I see. How was the file created? If there are no headers or meta data about the deflate stream, it can be hard to debug why the file cannot...

I tried reading from your data file, a single byte per read, and it seems like the deflate stream just ends after reading 208671 byte(s): ``` ❯ dotnet run Read...

If zlib gives the exact same result, it's the data (input file) that is the problem. The end looks a bit suspicious, perhaps you can just try removing the end...

Yes, something like that is what I meant, but not for the final solution, just to find out what parts of the file shouldn't be passed to INFLATE. I assume...

This project is focused on zip and tar.gz/bz2, so I have no insight into PDF, sorry. Plain DEFLATE is not that common in files, I would probably take a look...

@asyncritus great detective work! It could also be the case that the way they are reading/writing the checksum allows for truncating trailing null bytes. In the case of SharpZipLib it...

...or perhaps it's the tool that extracts out the PDF streams that strips the trailing null bytes? How did you produce the file?

It seems like the only thing we can do is to add a way to ignore the CRC (in the library, that is). It should be a useful option to...