[
https://issues.apache.org/jira/browse/COMPRESS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17073571#comment-17073571
]
Stefan Bodewig edited comment on COMPRESS-508 at 4/2/20, 10:02 AM:
-------------------------------------------------------------------
{{ZipArchiveInputStream}} does not do anything once it hits the block where
meta data is stored. In fact it will signal end of the stream. So technically
you get there by looping over all entries until {{getNextArchiveEntry}} returns
{{null}}, but that doesn't help you.
Please not that {{ZipFile}} doesn't need to use a {{File}}, it needs something
with random access and {{SeekableByteChannel}} is what provides this. So what
you'd need is a way to create a {{SeekableByteChannel}} from your URI. The most
simple solution for smaller archive would be to keep them in memory and use our
{{SeekableInMemoryByteChannel}}.
See
[http://commons.apache.org/proper/commons-compress/javadocs/api-1.20/index.html]
and
[http://commons.apache.org/proper/commons-compress/javadocs/api-1.20/index.html]
.
If you've got something that can reproduce the same {{InputStream}} over and
over again - like the URI - then one can probably implement
{{SeekableByteChannel}} on top of such a construct. Right now I'm not aware of
any, though.
was (Author: bodewig):
{{ZipArchiveInputStream}} does not do anything once it hits the block where
meta data is stored. In fact it will signal end of the stream. So technically
you get there by looping over all entries until {{getNextArchiveEntry}} returns
{{null}}, but that doesn't help you.
Please not that {{ZipFile}} doesn't need to use a {{File}}, it needs something
with random access and {{SeekableByteChannel}} is what provides this. So what
you'd need is a way to create a {{SeekableByteChannel}} from your URI. The most
simple solution for smaller archive would be to keep them in memory and use our
{{SeekableInMemoryByteChannel}}.
If you've got something that can reproduce the same {{InputStream}} over and
over again - like the URI - then one can probably implement
{{SeekableByteChannel}} on top of such a construct. Right now I'm not aware of
any, though.
> Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
> ---------------------------------------------------------------------
>
> Key: COMPRESS-508
> URL: https://issues.apache.org/jira/browse/COMPRESS-508
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
> Affects Versions: 1.20
> Environment: Android 9 and Android 10, on both emulator and real
> device .
> Reporter: AD_LB
> Priority: Major
> Attachments: 2020-03-31_20-53-36.png, 2020-04-01_18-28-19.mp4,
> ZipTest.zip, ZipTest2.zip, test.zip
>
>
> I'm trying to use ZipArchiveInputStream to iterate over the items of a zip
> file (which may or may not be a real file on the file-system, which is why I
> use a stream), optionally creating a stream from specific entries.
> One of the operations I need is to get the size of the files within.
> For some reason, it fails to do so. Not only that, but it throws an exception
> when I'm done with it:
> {code:java}
> Error:org.apache.commons.compress.archivers.zip.UnsupportedZipFeatureException:
> Unsupported feature data descriptor used in entry ...
> {code}
> I've attached here 3 files:sample project, the problematic zip file (remember
> that you need to put it in the correct path and grant storage permission),
> and a screenshot of the issue.
> Note that if I open the file using a third party PC app (such as
> [7-zip|https://www.7-zip.org/] ), it works fine, including showing the file
> size inside.
> Files:
> !2020-03-31_20-53-36.png![^test.zip]
> [^ZipTest.zip]
> Here's the relevant code (kotlin) :
>
> {code:java}
> thread {
> try {
> val file = File("/storage/emulated/0/test.zip")
> ZipArchiveInputStream(FileInputStream(file)).use {
> while (true) {
> val entry = it.nextEntry ?: break
> Log.d("AppLog", "entry:${entry.name} ${entry.size} ")
> }
> }
> Log.d("AppLog", "got archive ")
> } catch (e: Exception) {
> Log.d("AppLog", "Error:$e")
> e.printStackTrace()
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
