Bug with the zip fs provider (7u72, 8u25), am able to create a corrupted zip...

[Xueming Shen]

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.

-Sherman

On 1/16/15 10:07 AM, Xueming Shen wrote:
> Thanks Francis, I will take a look. It appears we have a bug 
> somewhere, the entry
> has the size field set to zero.
>
> sherman at sherman-linux:~/Workspace/test$ java jdk.nio.zipfs.ZipInfo 
> /tmp/t.zip
> ----------------#1--------------------
> [Central Directory Header]
>     Signature   :   0x02014b50
>     VerMadeby   :         0x14    [0, 2.0]
>     VerExtract  :         0x14    [2.0]
>     Flag        :        0x800
>     Method      :          0x8
>     LastMTime   :   0x46304f28    [Fri Jan 16 09:57:16 PST 2015]
>     CRC         :   0x3610a686
>     CSize       :          0x2
>     Size        :          0x0
>     NameLen     :          0x3    [foo]
>     ExtraLen    :          0x9
>         [tag=0x5455, sz=5, data= 07 fc 50 b9 54 ]
>          ->Info-ZIP Extended Timestamp: flag=7
>             *Fri Jan 16 09:57:16 PST 2015
>     CommentLen  :          0x0
>     DiskStart   :          0x0
>     Attrs       :          0x0
>     AttrsEx     :          0x0
>     LocOff      :          0x0
>
> [Local File Header]
>     Signature   :   0x04034b50
>     Version     :         0x14    [2.0]
>     Flag        :        0x800
>     Method      :          0x8
>     LastMTime   :   0x46304f28    [Fri Jan 16 09:57:16 PST 2015]
>     CRC         :   0x3610a686
>     CSize       :          0x2
>     Size        :          0x0
>     NameLength  :          0x3    [foo]
>     ExtraLength :         0x11
>         [tag=0x5455, sz=13, data= 07 fc 50 b9 54 fc 50 b9 54 fc 50 b9 
> 54 ]
>          ->Info-ZIP Extended Timestamp: flag=7
>             *Fri Jan 16 09:57:16 PST 2015
>             *Fri Jan 16 09:57:16 PST 2015
>             *Fri Jan 16 09:57:16 PST 2015
>
>
>
> On 01/16/2015 09:15 AM, Francis Galiegue wrote:
>> (sorry for the flurry of emails, I should really not press the send
>> button so quickly...)
>>
>> System info: Ubuntu 14.10; can reproduce with both 1.7u72 and 1.8u25.
>>
>> On Fri, Jan 16, 2015 at 6:10 PM, Francis 
>> Galiegue<fgaliegue at gmail.com>  wrote:
>>> OK, I have a more simple reproducer:
>>>
>>> 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();
>>>          }
>>>      }
>>> }
>>>
>>> Note that it doesn't matter whether I also .flush() before I close.
>>>
>>> -- 
>>> Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge
>>> JSON Schema in Java: http://json-schema-validator.herokuapp.com
>>> Parsers in pure Java: https://github.com/parboiled1/grappa (redde
>>> Caesaris: https://github.com/sirthias)
>>
>>
>