On 32 bit system those calls may fail if one tries to unpack files which
are bigger than 2GB.
Use large file system support to fix this problem.
Test: unpack a file bigger than 2GB on 32 bit Android systems
Change-Id: Ibd9bd5fc4a2f8dc7df98bd595f4fd1638a4f0d4a
Signed-off-by: Christian Poetzsch <christian.potzsch@imgtec.com>
FileWriter::Create() calls ftruncate(2) to truncate the destination
file, which doesn't work with FD that references a block device. It
leads to kIoError when calling ExtractEntryToFile() to extract an entry
to block device FD.
As a result, it fails the package_extract_file() command in OTA updates
(e.g. 'package_extract_file("boot.img",
"/dev/block/platform/soc.0/f9824900.sdhci/by-name/boot")').
This CL skips the call to ftruncate(2) if FD references a block device.
Bug: 32903624
Test: ziparchive-tests works.
Test: Build an OTA updater (m updater) and call package_extract_file().
Change-Id: Ia81116f1a8d7cab802396bdc32c6096b4cb56a3c
Point to log/log.h where necessary, define LOG_TAG where necessary.
Accept that private/android_logger.h is suitable replacement for
log/logger.h and android/log.h.
Correct liblog/README
Effectively a cleanup and controlled select revert of
'system/core: drop or replace log/logger.h' and
'system/core: Replace log/log.h with android/log.h'.
Test: compile
Bug: 30465923
Change-Id: Ic2ad157bad6f5efe2c6af293a73bb753300b17a2
Add two functions libziparchive that libminzip has. And create
corresponding unit tests.
1. Open a zip archive from a memory mapped region.
2. A new writer that takes a call back function pointer.
(Used by the OTA updater to stream the data.)
Test: Unit tests passed
Bug: 19472796
Change-Id: I2b2daec71174afe221030357e39bff5faea51e72
Should use android/log.h instead of log/log.h as a good example
to all others. Adjust header order to comply with Android Coding
standards.
Test: Compile
Bug: 26552300
Bug: 31289077
Change-Id: I33a8fb4e754d2dc4754d335660c450e0a67190fc
The boundary check of an invalid EOCD record may succeed due to the
overflow of uint32_t. Fix the check.
Test: Open the crash.apk and libziparchive reports the offset error as expected.
Bug: 31251826
Change-Id: I1d8092a19b73886a671bc9d291cfc27d65e3d236
(cherry picked from commit ae8180c06d)
system/core/include is included in the global include path using
-isystem, which hides all warnings. zlib.h is included through
system/core/include/ziparchive/zip_archive.h, which was hiding warnings
in it. Use a #pragma around the call to deflateInit2, it is a macro
that expands to an old-style cast, in preparation for moving from
-isystem to -I. Also move the ZipString constructor to zip_archive.cc
so it can assert on the length of the string parameter and fix an
implicit conversion from size_t to uint16_t.
Test: m -j native
Bug: 31492149
Change-Id: I74cdad7fe9c723859b5cfbea73c8f27d9d9ca265
ag/880725 modified ReadAtOffset to seek then read from the open
file descriptor. Previously pread64 was used to provide atomic
behaviour.
This causes races when multiple threads are trying to access data from
the file. This is supported, so this change reverts the relevant parts
of the above CL to restore the old behaviour.
Bug:27563413
Change-Id: I7bffd78da8c558745dfc3c072ba9691b1b15bb5b
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
(cherry picked from commit 8e6f722764)
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
This allows someone to stream the data out of a zip archive
instead of extracting to a file or to memory.
Included in this change is a small cleanup of the makefile.
Change-Id: I8b679a679c3502ff4ea0bc4f9e918303657fa424
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
Take mod_date into account as well, and fixes the issue where
all entries had creation dates in 1979.
Signed-off-by: beonit <beonit@gmail.com>
Change-Id: Id101794fa08218d15f2d1ba4e4a313c1807ea7aa
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
CYGWIN is not supported, USE_MINGW and HOST_OS==windows are being
replaced with LOCAL_..._windows variables.
Bug: 23566667
Change-Id: I3e4a1e4097dc994cf5abdce6939e83a91758fd75
Linking against both libziparchive-host and libz-host results in
libz loaded twice (because it is also linked statically in
libziparchive).
Change-Id: Ib34eef60200a702c2d7fbca3589b324992e78eab
since the struct is now used for other purposes. Also add some
comparator functions to the struct to simplify zip_archive.cc.
This is a follow-up CL for f1d3d3b247.
Bug: 21957428
Change-Id: I60d4171eeacc561d59226d946e9eb5f9c96d80cf
so that PackageManagerService can iterate over files with a
specific file extension like ".so".
(cherry picked from commit a4a80693d9)
Bug: 21957428
Change-Id: I36ba3c33a8b366a65f67cb6d156067c5caca1151
so that PackageManagerService can iterate over files with a
specific file extension like ".so".
Bug: 21957428
Change-Id: I76ed9560d4d1e00d297a97d518ec357166be1981
The objective of fallocate call seems to be to
make sure that we have enough enough space left
in the disk to house the uncompressed file.
But, fallocate is only supported in the following
file systems:
btrfs, ext4, ocfs2, and xfs
Return error only when fallocate fails due to
lack of space. The immediate ftruncate call is
going to take of the majority of other errors.
Bug: http://b/21558406
Bug: 21561449
Change-Id: I7083f3c7e5d745bd6e8a190ac9020297d638d9d4
(cherry picked from commit a68d0d1fe4)
We're already linking against libbase but we'll have to add
a libbase dependency to every target that includes libziparchive
as a STATIC_LIBRARY dependency, given that there's no way to
express that what we want (except by adding a LOCAL_WHOLE_STATIC_LIBRARY
dependency on libbase to libziparchive but that seems bad too)
Bug: http://b/21558406
Change-Id: I294ad389a9c61a1134a7bc323da25b0004a8f1e0
(cherry picked from commit e97e66ea7c)
It's unnecessary, and causes issues when the uncompressed
output is large.
Bug: http://b/21558406
Change-Id: I99cfb3933b094c2826c7e6c6de9aab03478fcc53
(cherry picked from commit f899bd534b)
The objective of fallocate call seems to be to
make sure that we have enough enough space left
in the disk to house the uncompressed file.
But, fallocate is only supported in the following
file systems:
btrfs, ext4, ocfs2, and xfs
Return error only when fallocate fails due to
lack of space. The immediate ftruncate call is
going to take of the majority of other errors.
Bug: 21561449
Change-Id: I7083f3c7e5d745bd6e8a190ac9020297d638d9d4
Linking against both libziparchive-host and libz-host results in
libz loaded twice (because it is also linked statically in
libziparchive).
bug: 21365909
Change-Id: Ie924e0b38e4c0811daff06e7c0bfed048e7ca82f
We're already linking against libbase but we'll have to add
a libbase dependency to every target that includes libziparchive
as a STATIC_LIBRARY dependency, given that there's no way to
express that what we want (except by adding a LOCAL_WHOLE_STATIC_LIBRARY
dependency on libbase to libziparchive but that seems bad too)
Change-Id: I294ad389a9c61a1134a7bc323da25b0004a8f1e0
There were crashes when android failed to extract
zip archives due to out of free space on disk, with stacks like:
#00 pc 00000000000156b0 /system/lib64/libc.so (memcpy+176)
#01 pc 000000000002e5b8 /system/lib64/libandroidfw.so
#02 pc 000000000002f488 /system/lib64/libandroidfw.so (ExtractToMemory+328)
#03 pc 000000000002f5c8 /system/lib64/libandroidfw.so (ExtractEntryToFile+268)
#04 pc 00000000000287d8 /system/lib64/libandroidfw.so (android::ZipFileRO::\
uncompressEntry(void*, int) const+12)
Space for the file is now allocated using fallocate rather than
ftruncate, since ftruncate dont actually reserve space on disk. When writes
to the mmaped pointer fails to be realized due to out of space SIGBUS
is the result. With this change we make sure that there is space available
before mmaping the pointer.
Change-Id: Ic5e8c33dbe729edb57919dacff73811b34cc2dc2
libziparchive fails to iterate some bootanimation archives
reporting invalid offset error. This is caused by failure
to process a directory with one file
(when name_offset + file_name_length == cd_offset).
Change-Id: I2733e7f782c14a6fadd5491bb94318ac968df206
Nobody ever called acquire() so release() was always
equivalent to delete. Just use delete instead so that
people can use unique_ptr directly (or shared_ptr if
they really want refcounts).
Change-Id: I9e3ad5e0f6a4fcc4e02e5a2ff7ef9514fe234415
Removed LOCAL_C_INCLUDES which are no longer necessary as zlib
now uses the LOCAL_EXPORT_C_INCLUDE_DIRS mechanism.
Removed a couple of redundant LOCAL_MODULE entries
Tested compiling some of the projects that make use of libziparchive
and libziparchive-host using a clean out dir with aosp_flounder-userdebug
aosp_arm-eng targets
make -j3 libziparchive libandroidfw libartd libart libjavacore libjavacoretests aapt
Change-Id: I2988f1b3a62d1df2b5eada4ad39a9246ac1184fb
With mingw 4.8, the new default packed behavior is broken and makes
zip archive fails due to unexpected misalignment in
CentralDirectoryRecord.
This patch uses -mno-ms-bitfields to revert to the old packed
behavior.
Change-Id: Ic977c841e330e19451db1d31ddb22e570a525062
There should never be a need of an entry name with \0 character.
Bug: 16162465
(cherry picked from commit 78271ba97b)
Change-Id: I68c72fb45e8ec70eb125cfc887488bc18ba5447d
It's important because entry names can be encoded in UTF-8 and can have \0
character in the middle.
Use vector instead of char* for prefix in IterationHandle.
Bug: 16162465
Change-Id: Ie34c8d7c6231cc258530c22bdde5542895213649
Add new public method to allow checkisc if an archive has entry names encoded in
UTF-8. If not then they will be encoded in IBM PC character encoding.
Bug: 16162465
Change-Id: I4468d76accca8a9b0b31cae8d43399ffc22cad42
in StartIteration. This method should always be called when the
iteration is over to make sure that we don't leak memory.
Change-Id: I5205c754dfafbab9bb5f06003c3663d2ec4e8a35
Given that all current & future android ABIs are
little endian, we can get rid of the explicit conversions
from memory regions to little endian data members.
Also cleans up a few C style casts that snuck in during
several -Werror efforts and fixes temporary file generation
on target.
bug: 15448202
Change-Id: I4fcbb3c1124cb82c82139d328344e54fc7895353
Currently CloseArchive doesn't call free and call sites don't appear
to either. I could not find any call sites which manually freed the
archive by deleting the handle. This fixes several memory leaks.
Change-Id: I21f187dde60fd87e6e54bde06de9e76fd0791104
