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

AD_LB edited comment on COMPRESS-508 at 4/3/20, 7:37 AM:
---------------------------------------------------------

I see. 

Could you please consider such a class?
 Maybe call it "ZipFileParser"?
 It would have "parseEntries" function, and then "getEntryInputStream" ?

This is to handle the case that the current library can't get entries sizes, 
yet all it has is a Uri to get the InputStream.

If not, can you please show how to use the option you wrote about, of ZipFile 
that handles it all in RAM? Perhaps it could be the most efficient (and maybe 
easiest too) in most cases, and in other cases I will choose a fallback of some 
sort.

BTW, This is all only available on this library, as I've found. I can't find 
those functionalities on other libraries, let alone the Android framework.

Thank you for the history bits. It's interesting. Do you think 7z is superior 
nowadays to zip ? Or do you think it has its own disadvantages and advantages ? 


was (Author: androiddeveloperlb):
I see. 

Could you please consider such a class?
Maybe call it "ZipFileParser"?
It would have "parseEntries" function, and then "getEntryInputStream" ?

This is to handle the case that the current library can't get entries sizes, 
yet all it has is a Uri to get the InputStream.

If not, can you please show how to use the option you wrote about, of ZipFile 
that handles it all in RAM? Perhaps it could be the most efficient (and maybe 
easiest too) in most cases, and in other cases I will choose a fallback of some 
sort.

This is all only available on this library, as I've found. I can't find those 
functionalities on other libraries, let alone the Android framework.

> 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)

Reply via email to