[
https://issues.apache.org/jira/browse/COMPRESS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17074319#comment-17074319
]
AD_LB commented on COMPRESS-508:
--------------------------------
Wait I don't think you understood me. I don't want to duplicate the file.
Are you saying that ZipFile can do this already ? Without caching entire file
into RAM or downloading it to a real file on storage?
Perhaps I will write it differently:
I just want to have 2 steps here, having 2 InputStreams if you need:
# Get the metadata of the zip file : all entries , with their names and sizes,
and extra stuff that are considered important (I'm not familiar with them).
# Being able, for each entry, to get an inputStream from it
In the end, it would be like of ZipFile, meaning that I have a list of them,
and be able to iterate over each, getting its information and being able to get
a stream from it if I want to.
I want to avoid ZipFile because it will either need a file-path or cache the
entire file into RAM (which might fail).
I suggested a solution that for step 1, it would cache (as temporarily as
possible, too) only the parts of the zip file that it needs. Not the data
itself. Only the rest. I don't know how efficient Zip files are formatted for
this, but my guess is that it should take much memory, and perhaps in the end
(and maybe even during this whole process) it would be about as good as ZipFile
handles things.
After step 1, you can iterate over the entries like on ZipArchiveInputStream,
but because you know the information about the entries, you can have the size
of each, even the zip file is problematic.
Of course, this is probably a lot of work, so I'm saying it all theoretically.
> 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)