Re: [compress] How to move forward with XZ support

2011-08-12 Thread Lasse Collin
On 2011-08-12 Stefan Bodewig wrote: > the GNU core utils come with an xz command Minor correction: GNU coreutils doesn't include compression tools. GNU gzip is its own package and so are bzip2 (bzip.org) and xz (tukaani.org). -- Lasse Collin | IRC: Larhzu @ IRCnet &a

Re: [compress] XZ support and inconsistencies in the existing compressors

2011-08-04 Thread Lasse Collin
On 2011-08-04 Stefan Bodewig wrote: > On 2011-08-04, Lasse Collin wrote: > > Using bits from the end of stream magic doesn't make sense, because > > then one would be forced to finish the stream. Using the bits from > > the block header magic means that one must add a

Re: [compress] ZIP64: API imposed limits vs limits of the format

2011-08-04 Thread Lasse Collin
d list etc. Keeping a list of 2^31-1 files will then need 100 GiB of RAM. While it might be OK in some situations, I hope such archives won't become common. ;-) Even if the number of files is limited to Integer.MAX_VALUE, it can be good to think about the memory usage of the data structures used

Re: [compress] XZ support and inconsistencies in the existing compressors

2011-08-04 Thread Lasse Collin
On 2011-08-04 Stefan Bodewig wrote: > On 2011-08-03, Lasse Collin wrote: > > I looked at the APIs and code in Commons Compress to see how XZ > > support could be added. I was especially looking for details where > > one would need to be careful to make different compressors be

[compress] XZ support and inconsistencies in the existing compressors

2011-08-03 Thread Lasse Collin
I would prefer depending on org.tukaani.xz because then there is just one code base to keep up to date. -- Lasse Collin | IRC: Larhzu @ IRCnet & Freenode - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org