[compress] Decompress Archive - Listener

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[compress] Decompress Archive - Listener

Karl Heinz Marbaise-3
Hi to all,

I have question concerning usage of commons-compress.

Is there an option to have a callback function / listener which can be
used to produce a kind of progress during decompressing archives (zip's,
tar, gz, etc.) ?

Unfortunately I haven't found a hint in the docs..or maybe I have
oversight it?


Kind regards
Karl Heinz Marbaise

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [compress] Decompress Archive - Listener

Stefan Bodewig
Hello Karl-Heinz

On 2018-03-13, Karl Heinz Marbaise wrote:

> Is there an option to have a callback function / listener which can be
> used to produce a kind of progress during decompressing archives
> (zip's, tar, gz, etc.) ?

No, there isn't.

There is an enhancement request to add something like that for the
decompression algorithms
https://issues.apache.org/jira/browse/COMPRESS-207 (actually the request
was for bzip2 specifically) and I even implemented a branch containing a
possible solution
https://github.com/apache/commons-compress/blob/COMPRESS-207/src/main/java/org/apache/commons/compress/compressors/CompressionProgressListener.java
but development never completed for one reason or the other.

For the archiving formats we haven't even ever thought of adding
something like that.

One problem with progress indicators is you need to have an idea of how
close you are to done. In the case of the compression formats you
surprisingly often don't know the decompressed size at all until you are
done decompressing. Likewise you have no idea how many files an archive
contains until you've read it completely for many formats (ZipFile and
7z are the main exceptions because we rely on random access and their
central directory).

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [compress] Decompress Archive - Listener

Karl Heinz Marbaise-3
Hi Stefan,

On 14/03/18 09:03, Stefan Bodewig wrote:

> Hello Karl-Heinz
>
> On 2018-03-13, Karl Heinz Marbaise wrote:
>
>> Is there an option to have a callback function / listener which can be
>> used to produce a kind of progress during decompressing archives
>> (zip's, tar, gz, etc.) ?
>
> No, there isn't.
>
> There is an enhancement request to add something like that for the
> decompression algorithms
> https://issues.apache.org/jira/browse/COMPRESS-207 (actually the request
> was for bzip2 specifically) and I even implemented a branch containing a
> possible solution
> https://github.com/apache/commons-compress/blob/COMPRESS-207/src/main/java/org/apache/commons/compress/compressors/CompressionProgressListener.java
> but development never completed for one reason or the other.
>
> For the archiving formats we haven't even ever thought of adding
> something like that.
>
> One problem with progress indicators is you need to have an idea of how
> close you are to done. In the case of the compression formats you
> surprisingly often don't know the decompressed size at all until you are
> done decompressing. Likewise you have no idea how many files an archive
> contains until you've read it completely for many formats (ZipFile and
> 7z are the main exceptions because we rely on random access and their
> central directory).

First thanks for your answer and to be honest I exaclty had expected
such kind of answer ;-) (except for the part COMPRESS-207)..

I understand the issues related to the reference point on which you say
you have for example 20% done (of what?)...

What about simply saying to make the reference on the whole file size
and how much you already have read.
This is of course not representing a progress related to number of files
or compressed/decompressed size etc. but could give a good impression
where you currently are...

And on the other hand I think it would work for all archive formats...

Kind regards
Karl Heinz Marbaise

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [compress] Decompress Archive - Listener

Stefan Bodewig
On 2018-03-17, Karl Heinz Marbaise wrote:

> On 14/03/18 09:03, Stefan Bodewig wrote:

>> On 2018-03-13, Karl Heinz Marbaise wrote:

>>> Is there an option to have a callback function / listener which can be
>>> used to produce a kind of progress during decompressing archives
>>> (zip's, tar, gz, etc.) ?

>> No, there isn't.

[...]

>> One problem with progress indicators is you need to have an idea of how
>> close you are to done. In the case of the compression formats you
>> surprisingly often don't know the decompressed size at all until you are
>> done decompressing. Likewise you have no idea how many files an archive
>> contains until you've read it completely for many formats (ZipFile and
>> 7z are the main exceptions because we rely on random access and their
>> central directory).

> I understand the issues related to the reference point on which you
> say you have for example 20% done (of what?)...

> What about simply saying to make the reference on the whole file size
> and how much you already have read.

Compress' interface is based on InputStream's, so in the general case
you don't even know the file size. Of course in many situations the
stream is a file stream but we can't make the progress interface rely on
it.

This is why the proposal for COMPRESS-207 only contained events for
"something interesting happened" like "I started a new internal stream"
or "I finished a bzip2 block" and those events always contained the
count of bytes read so far. We could even think about raising events
every 10k bytes read or something like that. Then the listener would
need to know the file size for example.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]