supporting huge zips

[Szczepan Faber-2]

Hey,

Is there are particular reason we explicitly configure Zip64Mode.Never for the ZipOutputStream? (https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/groovy/org/gradle/api/internal/file/copy/AbstractZipCompressor.java#L31)

This means that we don't support creating huge zips/jars (>~4G or >~65k entries) correctly (e.g. the creation of the archive succeeds but it does not seem to be openable).

There's a forum ticket that we transferred to jira: http://issues.gradle.org/browse/GRADLE-2964 I've also stumbled upon it at the client's.

Cheers!

--

Szczepan Faber

Principal engineer@gradle; Founder@mockito

[Stefan Bodewig]

On 2014-01-23, Szczepan Faber wrote:

> Hey,

> Is there are particular reason we explicitly configure Zip64Mode.Never for
> the ZipOutputStream? (
> https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/groovy/org/gradle/api/internal/file/copy/AbstractZipCompressor.java#L31
> )

I'm not exactly sure about gradle's reason to do so but it may be
related to docs I've written somewhere else :-)

Certain ZIP consumers will choke on Zip64 extensions even if they just
say "nothing to see here" - Java5's jar classes are an example for it.
AS_NEEDED or ALWAYS would create Zip64 extra fields inside the so called
local file header even if the entry doesn't need them.

Ant 1.9.0 used to default to AS_NEEDED and several people reported they
couldn't read the jars/zips created by Ant, so we made NEVER the default
for 1.9.1+'s jar family of tasks (but stuck with AS_NEEDED for zip
itself).

In either case, the Ant tasks provide an attribute to explicitly control
this.

Stefan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Szczepan Faber-2]

Thanks a lot for the info.

I think Gradle also needs to offer a way to control this behavior. Any objections?

Cheers!

On Thu, Jan 23, 2014 at 1:59 PM, Stefan Bodewig <[hidden email]> wrote:

On 2014-01-23, Szczepan Faber wrote:

> Hey,

> Is there are particular reason we explicitly configure Zip64Mode.Never for
> the ZipOutputStream? (
> https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/groovy/org/gradle/api/internal/file/copy/AbstractZipCompressor.java#L31
> )

I'm not exactly sure about gradle's reason to do so but it may be
related to docs I've written somewhere else :-)

Certain ZIP consumers will choke on Zip64 extensions even if they just
say "nothing to see here" - Java5's jar classes are an example for it.
AS_NEEDED or ALWAYS would create Zip64 extra fields inside the so called
local file header even if the entry doesn't need them.

Ant 1.9.0 used to default to AS_NEEDED and several people reported they
couldn't read the jars/zips created by Ant, so we made NEVER the default
for 1.9.1+'s jar family of tasks (but stuck with AS_NEEDED for zip
itself).

In either case, the Ant tasks provide an attribute to explicitly control
this.

Stefan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

--

Szczepan Faber

Principal engineer@gradle; Founder@mockito