Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

java.util.zip problem

41 views
Skip to first unread message

nestorac...@hotmail.com

unread,
May 8, 2003, 10:30:47 AM5/8/03
to
I'm using c# and J# java.util.zip library.
Almost everything works ok but when I try to compress multipage tiff
files using this library, I got an error.
I'm working with .net framework 1.0 and j# runtime 1.0
This is the error:

java.lang.ArrayIndexOutOfBoundsException: 65536
at java.io.FileInputStream.read(SByte[] buffer, Int32 offset, Int32
count)
at java.util.zip.ZipFile.readZIPEntries(String fname)
An unhandled exception of type 'java.util.zip.ZipException' occurred
in vjslib.dll

Nestor

Lars-Inge Tønnessen

unread,
May 8, 2003, 11:28:37 AM5/8/03
to
Could you please show us a code listing that will give us that exception?

Lars-Inge

Unknown

unread,
May 8, 2003, 3:04:41 PM5/8/03
to
I've having a weird problem as well, but using framwork 1.1
I get a zipexception that doesn't mean much when trying to call:

ZipFile zf = new ZipFile( "file.zip" );

This file.zip was created fine by using:
new ZipOutputStream(new java.io.FileOutputStream("file.zip")).close();

If I call new ZipFile( "file.zip" ) on the new empty file, all works well.
BUT,
as soon as I add a file to the file.zip and then call new ZipFile( "file.zip" ), I get an exception.

If I then go to winzip then look at the "file.zip" I have no problems extracting a file etc.

Is this a bug in the java lib that comes with VS.NET 2003?

thanks - bill


**********************************************************************
Sent via Fuzzy Software @ http://www.fuzzysoftware.com/
Comprehensive, categorised, searchable collection of links to ASP & ASP.NET resources...

Shankar Adhi [MSFT]

unread,
May 9, 2003, 9:39:09 AM5/9/03
to
This is a known issue in J# class library. It will be fixed possibly in
the next release of J#.
Work Around: Decompress your zip file and again compress it using winzip,
the new zip file should work.
Thanks for using J#.
ShankarA

--------------------
>>From: Bill Andreozzi (bill...@towncompass.com)
>>Subject: Re: java.util.zip problem
>>References: <838ffa3f.03050...@posting.google.com>
>>Message-ID: <OdPBvSZF...@TK2MSFTNGP10.phx.gbl>
>>Newsgroups: microsoft.public.dotnet.vjsharp
>>Date: Thu, 08 May 2003 12:04:41 -0700
>>NNTP-Posting-Host: shared2.orcsweb.com 66.129.69.1
>>Lines: 1
>>Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP10.phx.gbl
>>Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.vjsharp:3741
>>X-Tomcat-NG: microsoft.public.dotnet.vjsharp

--
ShankarA, Visual J# .NET Team
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


Tim Meagher

unread,
May 13, 2003, 11:35:31 AM5/13/03
to
I'm using the ZipUtils that Ianier developed as described in MSDN Magazine.
I'm having the problem when compressing the files - and the problem is
occurring with multi-page TIFs embedded in a PDF file. Since I am providing
a list of files (including multippl XML and multipage TIFs) to compress via
a call to the UpdateZipFile() method, is decompression taking place when
copying the temporary file (tmp) into the aggregate zipfile (prev) in the
call to "System.IO.File.Copy(tmp, prev, true)"? Is there a way to avoid
this?

Thx,

Tim Meagher

"Ianier Munoz" <ianier[nospam]@hotmail.com> wrote in message
news:#fa7vSfF...@TK2MSFTNGP10.phx.gbl...
> Hi Nestor,
> FYI, compression is OK. The problem is when decompressing the file.
> For example, the attached file fails to open with with the
> java.util.zip.ZipFile class. That is, new ZipFile("xx.zip") fails with the
> exception you mention. Winzip can open it without problems.
> Ianier
>
> <nestorac...@hotmail.com> wrote in message
> news:838ffa3f.03050...@posting.google.com...

Alex Niblett

unread,
May 13, 2003, 11:31:04 AM5/13/03
to
I am having this same problem with the ZipFile class when opening our
applications data, and WinZip has no problems with the same files. The
error message I get follows:

java.lang.ArrayIndexOutOfBoundsException: 65536
at java.io.FileInputStream.read(SByte[] buffer, Int32 offset, Int32
count)
at java.util.zip.ZipFile.readZIPEntries(String fname)

I really need a workaround or a fix for this. Is it fixed in .NET 2003?

Alex E. Niblett
Microsoft Certified Solution Developer
Senior Software Architect
Cornerstone Research
http://www.cstoneresearch.com


Tim Meagher

unread,
May 13, 2003, 12:44:41 PM5/13/03
to
A couple more notes here.

1. Upon review of Ianier's article, it is clear that the decompression and
re-compression is taking place as part of the copy:

"Copying an entry involves decompressing the entry from the source file ...
and recompressing it again to the destination file" (p.83, 2nd paragraph
under "Creating and Modifying Zip Files).

2. Although the exception

java.lang.ArrayIndexOutOfBoundsException: 65536
at java.io.FileInputStream.read(SByte[] buffer, Int32 offset, Int32
count)
at java.util.zip.ZipFile.readZIPEntries(String fname)

is occurring, the PDF files consisting of multi-page TIFs ARE getting
successfully copied into the aggregate zipfile, and when extracted, they
compare exactly the same. It makes me wonder if the problem is only in the
exception handling capabilities of the jsharp zip library.

- Tim Meagher

"Tim Meagher" <t...@aaom.net> wrote in message
news:uWcWZSWG...@TK2MSFTNGP12.phx.gbl...

Ianier Munoz

unread,
May 13, 2003, 1:42:48 PM5/13/03
to
Hi Tim,

> 1. Upon review of Ianier's article, it is clear that the decompression and
> re-compression is taking place as part of the copy:

Yes. The exception is thrown when the file is opened just after
recompression. If you exit the program at this point, you'll see that the
resulting file can be succesfully opened with Winzip.

> It makes me wonder if the problem is only in the
> exception handling capabilities of the jsharp zip library.

I tried the same code in a J# program and I got the same exception, so the
problem is definitely not related to J#/C# interoperability.
We could disassemble the vsjlib to get some clues :-), but I would prefer
that someone from MS explain what happens exactly.

Regards,
--
Ianier Munoz
http://www.chronotron.com


"Tim Meagher" <t...@aaom.net> wrote in message

news:%23i0wC5W...@TK2MSFTNGP12.phx.gbl...

Shankar Adhi [MSFT]

unread,
May 15, 2003, 10:01:22 AM5/15/03
to
This is a known issue in J# zip library. It will be fixed possibly in the
next release of J#.
Work Around: Decompress your zip file and again compress it using winzip,
the new zip file should work.
Thanks for using J#.
ShankarA

--------------------
>>From: "Ianier Munoz" <ianier[nospam]@hotmail.com>
>>References: <838ffa3f.03050...@posting.google.com>
<#fa7vSfF...@TK2MSFTNGP10.phx.gbl>
<uWcWZSWG...@TK2MSFTNGP12.phx.gbl>
<#i0wC5WG...@TK2MSFTNGP12.phx.gbl>
>>Subject: Re: java.util.zip problem
>>Date: Tue, 13 May 2003 19:42:48 +0200
>>Lines: 105
>>X-Priority: 3
>>X-MSMail-Priority: Normal
>>X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
>>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
>>Message-ID: <uxY#UcXGDH...@TK2MSFTNGP10.phx.gbl>
>>Newsgroups: microsoft.public.dotnet.vjsharp
>>NNTP-Posting-Host: dyn-81-191-155-133.ppp.tiscali.fr 81.191.155.133
>>Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP10.phx.gbl
>>Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.vjsharp:3766
>>X-Tomcat-NG: microsoft.public.dotnet.vjsharp

Tim Meagher

unread,
May 15, 2003, 11:23:35 PM5/15/03
to
I opened a ticket with Microsoft. Here's what I've heard back so far:

"I was able to debug into the JSharp zip code and the exception is being
thrown because the pdf file contains some invalid (from J#'s point of view)
data. It's looking for one of the following:

local file header signature - 0x04034b50

Central file header signature - 0x02014b50

End of central dir signature - 0x06054b50

As we are reading through the ZipFileEntries in the PDF file we are
expecting to see one of these values, if we don't we throw the ZipException.
Can you get this exception with an actual .zip file? The PDF file may add
some data that we don't recognize, and that might very well be the cause of
the problem."


I responded to Microsoft and indicated that the problem was not specific to
a PDF file - in fact I provided a multi-page tiff file which also resulted
in an exception. It occurred to me that I should try to create the archive
with WinZip and then try to decompress it with the jsharp libraries - again
using Ianier's ZipUtils wrappers. This time the decompression was
successful. This leads me to believe that the exception may be thrown
because the jsharp zip compression is not able to properly embed the
necessary information in the archive for multi-page tiff files that are
subsequently decomperssed.

I will continue to report on my findings from Microsoft as they become
available.

- Tim

"Ianier Munoz" <ianier[nospam]@hotmail.com> wrote in message

news:uxY#UcXGDH...@TK2MSFTNGP10.phx.gbl...

Ianier Munoz

unread,
May 16, 2003, 3:08:59 AM5/16/03
to
Hi Tim,
Thanks for the info.
If the problem is related to certain byte sequence, a workaround would be to
encode the file in some way before compressing it (for example, base64).
This approach would be OK for compressing application-specific data.
Regards,
Ianier


"Tim Meagher" <t...@aaom.net> wrote in message

news:OORVOn1G...@TK2MSFTNGP10.phx.gbl...

Tim Meagher

unread,
May 17, 2003, 10:06:01 AM5/17/03
to
Here's the latest scoop on the zip problem. Microsoft Technical Support has
determined that the problem occurs when the internal method ReadZipEntries
gets called. It truly is an ArrayOutOfBounds exception (it purportly wasn't
written to adequately handle larger zip files). This method gets called
AFTER the compression and decompression has taken place - in fact it is
called when a new ZipFile object is created - hence the error when returning
from Ianier's UpdateZipFile wrapper. It appears that the exception is
non-destructive and that there is no problem with the actual compression and
decompression - but a request has been sent to the development team to
determine if the exception can be ignored and to create a hotfix/patch
and/or to fix it in the next release.

For now it looks like one can merely catch and ignore the exception.

Regards,

Tim

"Ianier Munoz" <ianier[nospam]@hotmail.com> wrote in message

news:eSkyQo3G...@tk2msftngp13.phx.gbl...

0 new messages