JDK-8069211 : (zipfs) ZipFileSystem creates corrupted zip if entry output stream gets closed more than once
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 7,7u25,8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-01-16
  • Updated: 2020-11-30
  • Resolved: 2015-01-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9 Other
8u281Fixed 9 b48Fixed openjdk8u282Fixed
Related Reports
Duplicate :  
Description
public final class Jsr203ZipBug
{
    public static void main(final String... args)
        throws IOException
    {
        final Path zipPath
            = Paths.get(System.getProperty("java.io.tmpdir"), "t.zip");
        Files.deleteIfExists(zipPath);

        final URI uri = URI.create("jar:" + zipPath.toUri());

        final Map<String, ?> env = Collections.singletonMap("create", "true");

        try (
            final FileSystem zipfs = FileSystems.newFileSystem(uri, env);
            final OutputStream out
                = Files.newOutputStream(zipfs.getPath("/foo"));
        ) {
            out.write("hello".getBytes());
            out.close();
        }
    }
}

Comments
8u review approval: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-November/013089.html
25-11-2020

Fix Request (8u) I would like to backport this patch to OpenJDK8u for parity with Oracle 8u281. The original patch does not apply cleanly. 8u patch has been reviewed.
30-10-2020

8u code review: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-October/012779.html
09-10-2020

There is a bug in ZipFileSystem.EntryOutputStream.close(). The current implementation does not prevent you from writing/closing into the stream after you have closed it. The second close will basically reset the size to wrong number... You test case close the stream twice, one is the explicit close, on by the try/catch. Will file a bug. The temporary workaround is to either remove the "out" out of the try/catch auto-close one or don't close it explicitly.
16-01-2015