Using NIO2 for writing zip file entries without corresponding folder entries

[Rafael Winterhalter]

Hi Alan,
you are right about being allowed to reuse an existing directory, my use
case is however slighty different. It is about bundeling several zip files
into a single file:

        Path sample = Files.createTempFile("source", ".zip");
        Path other = Files.createTempFile("target", ".zip");

        // Emulate original input
        try (ZipOutputStream outputStream = new
ZipOutputStream(Files.newOutputStream(sample))) {
            outputStream.putNextEntry(new ZipEntry("foo/bar.txt"));
            outputStream.write(new byte[] { 1, 2, 3 });
            outputStream.closeEntry();
        }
        try (ZipOutputStream outputStream = new
ZipOutputStream(Files.newOutputStream(other))) {
            outputStream.putNextEntry(new ZipEntry("qux/baz.txt"));
            outputStream.write(new byte[] { 4, 5, 6 });
            outputStream.closeEntry();
        }

        // Emulate merging two zip files without directories using NIO2
        try (
            FileSystem source = FileSystems.newFileSystem(sample, null);
            FileSystem target = FileSystems.newFileSystem(other, null)
        ) {
            Path path = source.getPath("foo/bar.txt");
            Files.copy(path, target.getPath(source.toString()));
        }

It surprised me that this does not work when trying to migrate from
ZipInputStream to NIO2.

And yes, you are absolutely right about the target system that is
processing the file is the actual problem. It is running on a mainframe
that nobody wants to touch anymore, however, so we are stuck with
worarounds.

Thanks for your input! Best regards, Rafael

Am Mi., 10. Okt. 2018 um 14:59 Uhr schrieb Alan Bateman <
Alan.Bateman at oracle.com>:

> On 10/10/2018 13:00, Rafael Winterhalter wrote:
> > You are right with that it does emulate missing folders in the source
> > file.
> >
> > I have a use case where I patch a zip file with some additional
> > entries that are placed in directories of files that already exist in
> > the zip file. To do so, I have to add the directories for the added
> files.
> I just tried a quick test with a zip file containing one entry x/foo.txt
> (created with zip -D to not create directory entries). With the zip file
> system then I replaced x/foo.txt, then a second test to create x/bar.txt
> and I didn't see any issues. Is that close to what you are doing? I
> suspect most usages of the zip file system provider are read-only (javac
> being the biggest user) and it's possible there are issues or short
> comings when writing or updating that haven't come up. If you can
> provides the instructions or a simple test case to show what you are
> seeing then it would be useful. Also which JDK release is this?
>
> > Doing so confuses the processing backend which does not filter the
> > folder entries but treats them as normal files which causes this
> > processor to crash when treating them as regular files.
> This sounds like a bug in whatever this system is as many zip tools will
> create directory entries by default.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20181016/888c0df2/attachment.html>