You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Peter Lee (Jira)" <ji...@apache.org> on 2021/09/13 11:47:00 UTC

[jira] [Resolved] (COMPRESS-585) ZipFile fails to read a zipfile with a comment or extra data longer than 8024 bytes

     [ https://issues.apache.org/jira/browse/COMPRESS-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Lee resolved COMPRESS-585.
--------------------------------
    Resolution: Fixed

> ZipFile fails to read a zipfile with a comment or extra data longer than 8024 bytes
> -----------------------------------------------------------------------------------
>
>                 Key: COMPRESS-585
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-585
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Archivers
>    Affects Versions: 1.21
>            Reporter: Matthijs Laan
>            Priority: Minor
>         Attachments: COMPRESS-585-test.patch
>
>
> See the attached patch for a unit test demonstrating the issue with a long comment.
> The cause is that {{ZipFile.readCentralDirectoryEntry()}} calls {{IOUtils.readRange()}} and assumes if it returns less than the length it asked for that the EOF is reached, however this is not how that method works: it returns max COPY_BUF_SIZE bytes (8024), even if EOF has not been reached.
> Besides comments and extra data (in the central directory or local file header) longer than 8024 bytes the only other place {{readRange()}} is called is reading filenames, but that seems like a remote edge case and an EOF exception is fine.
> The IOUtils.readRange() JavaDoc does not specify how it communicates EOF. With a blocking channel this would be when it returns a zero length array. It could throw an exception when {{Channel.read()}} returns 0 bytes, because that only happens on non-blocking channels.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)