Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
From: Stefan Bodewig <bodewig@apache.org>
To: dev@commons.apache.org
Subject: Re: [compress] ZIP64: API imposed limits vs limits of the format
References: <87aabp1bd1.fsf@v35516.1blu.de>
	<CAEQx=x=GycPB+HN6x1eV01wWE6mV8Ebjd6pTeCoqnSDAdHhSVw@mail.gmail.com>
Date: Fri, 05 Aug 2011 14:49:47 +0200
In-Reply-To: 
 <CAEQx=x=GycPB+HN6x1eV01wWE6mV8Ebjd6pTeCoqnSDAdHhSVw@mail.gmail.com>
	(Torsten Curdt's message of "Thu, 4 Aug 2011 17:03:56 +0200")
Message-ID: <87wresauqc.fsf@v35516.1blu.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 2011-08-04, Torsten Curdt wrote:

>> ZipFile relies on RandomAccessFile so any archive can't be bigger than
>> the maximum size supported by RandomAccessFile. =C2=A0In particular the =
seek
>> method expects a long as argument so the hard limit would be an archive
>> size of 2^63-1 bytes. =C2=A0In practice I expect RandomAccessFile to not
>> support files that big on many platforms.

> Yeah ... let's cross that bridge when people complain ;)

With that I can certainly live.

>> For the streaming mode offsets are currently stored as longs but that
>> could be changed to BigIntegers easily so we could reach 2^64-1 at the
>> expense of memory consumption and maybe even some performance issues
>> (the offsets are not really used in calculations so I don't expect any
>> major impact).

> No insights on the implementation but that might be worth changing so
> it's in line with the ZipFile impl

ZipFile is already limited to longs via RandomAccessFile.

>> I'm confident that even I would manage to write an efficient singly
>> linked list that is only ever appended to and that is iterated over
>> exactly once from head to tail.

> +1 for that then :)

Lasse's post showing that I'd need 100+ GB of RAM to take advantage of
my bigger LinkedList made me drop that plan 8-)

If anybody is really dealing with archives that big they likely don't
use Commons Compress and if they do then support for archives split into
multiple files might be more important.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org