Older implementations of ZIP (Java's ZipInputStream) don't
like a Data Descriptor trailing after an uncompressed entry.
If the FILE is seekable, and the entry is uncompressed, seek
back to the header and write out the crc and sizes.
(cherry-pick of commit 639814d946)
Bug: 36686974
Test: make ziparchive_tests
Change-Id: I61664515e5afa3e2ba814874eeac847a2aaac319
Based on the compressed size of a file entry,
the decision needs to be made to instead store the file
uncompressed. This adds support to ZipWriter to backup
its last file entry.
The file is now always truncated when the EOCD is written out,
to account for the case where a file entry is backed-up and the
resulting file written is much smaller, leaving garbage data at
the end of the file.
This change also includes a rename of FileInfo -> FileEntry.
This struct was private (now public), so it shouldn't affect any
clients.
Bug: 35461578
Test: make ziparchive-tests
Change-Id: I23dc584406274ab7b8ce62b3fbc3562ca4c2603e
Also use ReadFully to replace read, because read can
return reading bytes less than requested. And use
WriteFully to replace write.
Bug: 26962895
Change-Id: Iff0b2bc6d925619a537f7fef682c2a7ad89a2dc2
The code does not handle an edge case where writing a compressed
image can overflow the avail_out data when doing a flush. Add a
loop to keep writing the data while deflate indicates that it doesn't
have enough space to write out the compressed data during the flush.
Change-Id: I1f1d1646457ed9b67ed24f6582688c300186c23c
The ZipWriter implementation exposes a stateful interface that allows
bytes of data to be streamed in as they arrive. ZipEntries can be
compressed and/or aligned on a 32-bit boundary for mmapping at runtime.
Change-Id: I43ac9e661aa5022f00d9e12b247c4314d61c441c
Adam Lesinski
Yabin Cui
Christopher Ferris
Elliott Hughes