<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
On 23/02/2023 16:32, Lance Andersen wrote:<br>
<blockquote type="cite" cite="mid:9B315E4F-C51D-47F3-B7CC-EE750FEC1275@oracle.com">
HI Eirik<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Feb 23, 2023, at 7:43 AM, Eirik Bjørsnøs <<a href="mailto:eirbjo@gmail.com" class="moz-txt-link-freetext" moz-do-not-send="true">eirbjo@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Hi,<br class="">
<div class=""><br class="">
</div>
<div class="">While writing various ZIP related tests, I
noticed a discrepancy in the treatment of invalid CRC
values:</div>
<div class=""><br class="">
</div>
<div class="">While ZipInputStream rejects invalid CRC
values when consuming streams, ZipFile and ZipFileSystem
do not.</div>
<div class=""><br class="">
</div>
<div class="">While this is inconsistent, it is perhaps
not a bug we want to fix?</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
I believe it is intentional. Alan, Martin B, do you recall the
history?<br>
</div>
</blockquote>
<br>
I think Dave Bristor or Martin looked at this at one point so you
might have to search JBS for issues where they commented on this
topic.<br>
<br>
As a general point, the ZIP format can have redundant metadata and
there can be cases where the CRC-32 isn't available when writing a
LOC header. At the same time, the APIs work differently in that
ZipFile opens a ZIP file so it has access to the CEN whereas
ZipInputStream is working on a stream of ZIP entries and does not
read the CEN. So some inconsistencies in the handling is not too
surprising.<br>
<br>
-Alan<br>
</body>
</html>