With ag/20611145, the dir size is not uint32max by default. Update the
value in the test accordingly.
(The test was not discovered in CI because gotestrunner
runs the tests using `-test.short` flag, and skips this test)
Test: go test ./third_party/zip -run TestZip64P7ZipRecords
Change-Id: I47885f23fe32ff5ed30c44d52561cd11d59020ec
Only store uintmax for the number of entries in the regular end record
if it doesn't fit. p7zip 16.02 rejects zip files where the number of
entries in the regular end record is larger than the number of entries
counted in the central directory.
Fixes: 187485108
Test: TestZip64P7ZipRecords
Change-Id: I0d116e228a0ee26e4e95bb3f35771da236a056eb
If the length of a stored file is more than 2^32 and a data descriptor
is not being used then a ZIP64 extra is required in the file header to
store the uncompressed and compressed lengths.
Bug: 175055267
Test: TestCopyFromZip64
Change-Id: Id414b4c04f48aefabfd835bd8339333d36576375
The extended-timestap extra block changes between Local File Header and
Central Directory. We have to strip it out to avoid mis-filling during
zip2zip.
Bug: b/65455145
Test: add unit-test.
Change-Id: I17e3f6c10fd6a068019620b4426f6042f6fac317
This was blindly copying the zip64 extra fields from the central
directory of the original zip file to the new one. The zip64 extra
fields depend on the contents of the header it's attached toa, and in
this case we were copying the zip64 file header offset from the central
directory entry into the destination local file header, which makes no
sense, especially since the offset changed in the new file.
So strip all zip64 extra entries, and we'll create them as necessary
when writing ou the new file.
Bug: 34704111
Test: zip2zip on the original target-files -> img that was broken
Test: m -j blueprint_tools (new android_test.go)
Change-Id: Ie3c0540b13d3afcf42f3d47fff319065952b126f
