> The TestTooManyEntries test was originally added to validate that ZIP64 files > with CEN sizes exceeding what ZipFile supports are rejected with a > ZipException. The test does this by creating a large ZIP file (several > gigabytes) with many enties. Because this is resource intensive, the test is > currently tagged as manual. (See #6927) > > It would be useful to have a test which asserts the CEN size enforcement, but > without the CPU, disk, memory and run time requirements of > TestTooManyEntries. Such a fast test can run non-manual, without the > @requires and manual tags as found in TestTooManyEntries. > > This PR adds the EndOfCenValidation test which creates sparse test ZIPs where > the CEN is "inflated" such that is matches the size declared in the "End of > central directory" records. > > While thee sparse files look large, they consume very little disk space on > file systems supporting sparse files: > > > 16 -rw-r--r-- 1 2147483702 Feb 6 18:54 bad-cen-offset.zip > 16 -rw-r--r-- 1 2147483703 Feb 6 18:54 cen-size-too-large.zip > 8 -rw-r--r-- 1 132 Feb 6 18:54 invalid-zen-size.zip > ``` > > For good measure, two new test methods are added to excercise the remaining > ZipExceptions which ZipFile may throw during validation of the END record .
Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: Consistently refer to the ultimate ZIP header/record like this: 'End of central directory record' (END header) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12231/files - new: https://git.openjdk.org/jdk/pull/12231/files/1b253a14..a93248f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12231&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12231&range=02-03 Stats: 13 lines in 1 file changed: 2 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/12231.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12231/head:pull/12231 PR: https://git.openjdk.org/jdk/pull/12231
