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: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
