Seems commons compress is unable to generate a Zip64 in a streamed fashion and can only do that from existing file so I guess the only way to fix this would be to first serialized the pages on the filesystem and then generate a ZIP. I guess it could be an option in the XAR output filter and in the the Export Admin UI.
My understanding from reading the documentation is that the problem is the output stream, not the input stream. So in other words, I think the problem is that we let the ZIP stream directly write to the response in the export action, a fix would be to simply write the ZIP file to a temporary file first before sending it in the response. This seems a much smaller change than writing all pages to the filesystem.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
