[jira] [Commented] (COMPRESS-652) Support appending to existing archives in ZipArchiveOutputStream

["Gary D. Gregory (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COMPRESS-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787640#comment-17787640 ] 

Gary D. Gregory commented on COMPRESS-652:
------------------------------------------

Hello [~djanus]
Thank you for your report.
The best way to get you work reviewed is to create a PR on GitHub. You'll want to make sure to have code coverage in new tests for the changes.

> Support appending to existing archives in ZipArchiveOutputStream
> ----------------------------------------------------------------
>
>                 Key: COMPRESS-652
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-652
>             Project: Commons Compress
>          Issue Type: New Feature
>            Reporter: Daniel Janus
>            Priority: Major
>
> h2. Problem
> The Zip format is amenable to appending entries to an archive without having to regenerate it from scratch. It is sufficient to read the central directory, trim the archive just before it, add new entries, and then regenerate the central directory at the end.
> It isn't hard to add support for this to {{{}ZipArchiveOutputStream{}}}. ZipFile can already read the central directory, so I envision a {{ZipFile#append()}} method that would convert an already-created {{ZipFile}} to a {{{}ZipArchiveOutputStream{}}}.
> h2. Implementation
> I've taken a stab at implementing this. My branch is [here|https://github.com/nathell/commons-compress/tree/append-zip]. It works well in my preliminary testing, but before this can be merged, it probably needs some extra measures. For example, the current implementation won't work with multipart archives, but doesn't check whether the origin ZipFile is multipart. Also, I haven't tested zip64.
> I'd love to receive feedback and work on making this mergeable!  Java is not my daily driver (Clojure is), so I might have violated some best practices.
> h2. Context
> I've encountered a need for this in an ETL-type system that repeatedly augments a 'current' zip file with new changes ingested from external data sources. Currently, I'm using ZipFileSystem, but it's suboptimal.
> Other people are sometimes looking for this functionality; see [here|https://stackoverflow.com/questions/2993847/append-files-to-an-archive-without-reading-rewriting-the-whole-archive?rq=1] or [here|https://stackoverflow.com/questions/2223434/appending-files-to-a-zip-file-with-java] for examples.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)