Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZipInputStream stop finding next entry if entry is a folder with Data Descriptor #309

Closed
LeeYoung624 opened this issue Apr 16, 2021 · 3 comments
Assignees
Labels
bug Something isn't working resolved

Comments

@LeeYoung624
Copy link
Contributor

ZipInputStream stop finding next entry if entry is a folder with Data Descriptor. This zip could be extracted by unzip in Linux.

Seems this is caused by ZipInputStream.readUntilEndOfEntry

    if (localFileHeader.isDirectory()
        || (localFileHeader.getCompressedSize() == 0 && !localFileHeader.isDataDescriptorExists())) {
      return;
    }
@srikanth-lingala
Copy link
Owner

I will try to reproduce this

@srikanth-lingala
Copy link
Owner

Fixed in v2.8.0 released today.

@mbach979
Copy link

mbach979 commented Sep 1, 2021

I believe this issue is still not fixed (tested in 2.9.0). The attached simple example of writing a zip archive with just two directories using ZipOutputStream and then reading with ZipInputStream fails to read the second entry.

The offending code seems to be in ZipInputStream.read(byte[], int, int) lines 155-157:
if (localFileHeader.isDirectory()) { return -1; }
Since this stops reading before endOfCompressedDataRecord() can be called, and subsequently read the data descriptor block. Reading the next entry then silently fails because the signature is for a data descriptor and not a local file header.

Zip4jDirectoryDataDescriptorBug.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working resolved
Projects
None yet
Development

No branches or pull requests

3 participants