[ 
https://issues.apache.org/jira/browse/COMPRESS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17074466#comment-17074466
 ] 

AD_LB edited comment on COMPRESS-508 at 4/3/20, 10:35 AM:
----------------------------------------------------------

Peter Lee 

1. I tested this now. Other than (again) not being able to use 
"ZipEncodingHelper.UTF8" (because it's not public, no idea how you reach it), 
it seems to work well:

{code:kt}
                ZipArchiveInputStream(FileInputStream(file), "UTF8", true, 
true).use { inputStream ->
                    var entry: ArchiveEntry? = null
                    var nextEntry: ArchiveEntry? = null
                    while (true) {
                        entry = nextEntry ?: inputStream.nextEntry ?: break
                        nextEntry = null
                        if (entry.size < 0) 
                            nextEntry = inputStream.nextEntry
                        Log.d("AppLog", "entry:${entry.name} ${entry.size} ")
                    }
                }
{code}

 [^ZipTest3.zip] 

You say it's a good workaround to get the information of the entries?
After that, I would have to create a new ZipArchiveInputStream, right?

2. I see. Can you please show how to use the whole-file-in-mem technique? Only 
the first few lines, of course. No need for the entries if that's obvious 
anyway :)

Maybe I will use the memory solution if possible, and the 2 
ZipArchiveInputStream method when not possible.

[~bodewig]
Is it a lot of code? What should I worry about?
Is it possible to know how much memory it will need? It's about the same as the 
size of the file, right? But it's a bit problematic to know the size of an 
InputStream sometimes.
Is it possible to tell it "take up to this much RAM, but if you can't, tell me 
about it" ? 


was (Author: androiddeveloperlb):
Peter Lee 

1. I tested this now. Other than (again) not being able to use 
"ZipEncodingHelper.UTF8" (because it's not public, no idea how you reach it), 
it seems to work well:


{code:kt}
                ZipArchiveInputStream(FileInputStream(file), "UTF8", true, 
true).use { inputStream ->
                    var entry: ArchiveEntry? = null
                    var nextEntry: ArchiveEntry? = null
                    while (true) {
                        entry = nextEntry ?: inputStream.nextEntry ?: break
                        nextEntry = null
                        if (entry.size < 0) 
                            nextEntry = inputStream.nextEntry
                        Log.d("AppLog", "entry:${entry.name} ${entry.size} ")
                    }
                }
{code}

You say it's a good workaround to get the information of the entries?
After that, I would have to create a new ZipArchiveInputStream, right?

2. I see. Can you please show how to use the whole-file-in-mem technique? Only 
the first few lines, of course. No need for the entries if that's obvious 
anyway :)

Maybe I will use the memory solution if possible, and the 2 
ZipArchiveInputStream method when not possible.

[~bodewig]
Is it a lot of code? What should I worry about?
Is it possible to know how much memory it will need? It's about the same as the 
size of the file, right? But it's a bit problematic to know the size of an 
InputStream sometimes.
Is it possible to tell it "take up to this much RAM, but if you can't, tell me 
about it" ? 

> 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, ZipTest3.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)

Reply via email to