Lotus Notes Viewer not opening ZIP files created using Java

[David Zwerlin]

PLEASE HELP RESOLVE THIS BUG...

We have a Java Notes agent in a Domino application which automatically
creates reports in Zip format and sends them to several users on a daily
basis. The Lotus Notes R5/R6/R7 View action button in the Attachment
property box does not work for Zip files created using Java. My users
are becoming frustrated! This issue seems to a pending bug for the last
7 years. Does anyone from IBM or any Java developers have an answer to
this issue ?

FYI

Notes viewer - Java Zip issue posted in year 2000:
http://groups.google.com/group/comp...gst&q=lotus+notes+java+zip+view&rnum=1&hl=en#
__________________________________________________
Newsgroups: comp.lang.java.programmer
From: "rjb" <[email protected]>
Date: 2000/05/23
Subject: java.util.zip Problem?? Help
Reply to author | Forward | Print | Individual message | Show original |
Report this message | Find messages by this author
We have a servlet that creates a report and attaches it as a .ZIP file
attachment. The problem seems to be that the format of the .ZIP file is not
quite right. We can open this with most programs for .ZIP files, but the
following fails:

When a user receives the attachment in Lotus Notes4.6.x, and chooses the
View Attachment option, the system returns the following error message:-

The file is corrupt.

Is there some deviation from the .ZIP file standard by Sun. I have tried
this using both JDK1.1.7 on Linux, and JDK1.2.2 on Win9X/NT and Linux - both
result in the same problem. If I create a file using WinZip or PKZIP, Lotus
Notes does not have a problem with the file at all.

Any suggestions?
_______________________________________________________
REPLY 1:

Newsgroups: comp.lang.java.programmer
From: (e-mail address removed) (Peter van der Linden)
Date: 2000/05/23
Subject: Re: java.util.zip Problem?? Help
Reply to author | Forward | Print | Individual message | Show original |
Report this message | Find messages by this author

>When a user receives the attachment in Lotus Notes4.6.x, and chooses the
>View Attachment option, the system returns the following error message:-

>The file is corrupt.

>Is there some deviation from the .ZIP file standard by Sun.

The zip format used in Java is intended to be absolutely the
standard zip format.

Can you use a binary dump program to see where the difference is?
Can you use that to try to boil it down into the simplest example that
fails? Also check for bugs at the JDC site (address in Java FAQ).

Please report back what you find, this looks interesting.

The Java FAQ is at
http://www.afu.com
_______________________________________________________
REPLY 2:

Newsgroups: comp.lang.java.programmer
From: "rjb" <[email protected]>
Date: 2000/05/25
Subject: Re: java.util.zip Problem?? Help
Reply to author | Forward | Print | Individual message | Show original |
Report this message | Find messages by this author
I have zipped a sinlge 2KB file using both methods, and there is a
difference. However, even using the basic no frills options in all other
programs, I cannot put my finger on the reason for this.
FYI -
Zipped with Zip under Linux - Lotus Notes recognises
Zipped with PKZip under Dos - Lotus Notes recognises
Zipped with WinZip7.0 - Lotus Notes recognises
Zipped with WinZip8.0 - Lotus Notes recognises
Zipped with java.util.zip - Lotus Notes says it is corrupt, but I can open
with WinZip et al.

Now, if I was a betting man, I'd have my money on Sun either doing something
funny. Will check the JDC.

regards
_______________________________________________________
REPLY 3:

Newsgroups: comp.lang.java.programmer
From: Marco Schmidt <[email protected]>
Date: 2000/05/26
Subject: Re: java.util.zip Problem?? Help
Reply to author | Forward | Print | Individual message | Show original |
Report this message | Find messages by this author

>I have zipped a sinlge 2KB file using both methods, and there is a
>difference. However, even using the basic no frills options in all other
>programs, I cannot put my finger on the reason for this.

Maybe you can make that ZIP archive created from your Java app
available for download via HTTP?! I would take a look at it.

There usually is a small difference in ZIP archives created by
different programs (or with different compression ratio settings).

Regards,
Marco

 

[Chris Uppal]

We have a Java Notes agent in a Domino application which automatically
creates reports in Zip format and sends them to several users on a daily
basis. The Lotus Notes R5/R6/R7 View action button in the Attachment
property box does not work for Zip files created using Java. My users
are becoming frustrated! This issue seems to a pending bug for the last
7 years. Does anyone from IBM or any Java developers have an answer to
this issue ?

I know of no reason to think that Java is creating ZIP files which are in any
way abnormal (and I've written a ZIP file decoder myself, so I do know a little
about the subject). I'd guess that it's a bug in Notes.

However, without further information -- which can only come from the Notes
developers -- I don't see how anyone in the Java world can do more than
speculate.

So the rest of this post is mere speculation...

My /guess/ (and it is only a guess) is that the problem comes somewhere as
Notes attempts to find the "central directory" in the ZIP file. The logic for
doing that involves starting at the end of the file and scanning backwards
looking for a specific bit-pattern, it is then necessary (if you want
reliability) to use some heuristics to check that the data you find immediately
after that bit-pattern makes sense (since the pattern can occur naturally too).
If the heuristics used by Notes are over-strong (i.e. the make some invalid
assumptions) then I can imagine it rejecting Java-generated ZIPs incorrectly.

Another possibility --- remote -- is that something in the data transfer chain
is changing the ZIP file in a way that causes Notes to reject it (presumably
the Java-generated ZIPs reach the users via a different route from your test
ZIPs created with different tools). For instance I recently came across a case
where a couple of ZIPs had (in some unknown way) had '\r\n' appended to them.
That doesn't bother most ZIP readers, but /does/ bother my own implementation.
My heuristic checks are stricter than most, and my code (which I may decide to
change) checks that the data /after/ the bit-pattern should reach exactly up to
the end of the file -- so random data stuck on the end causes it (correctly,
IMO) to fail.

-- chris

 

[Chris Uppal]

[I meant to include this in my earlier post, but managed to press send while
the edit window was still open on the later draft....]

So the rest of this post is mere speculation...

Another remote possibility is that Notes is unable to deal with ZIPs where any
entry's size and checksum data /follow/ the item's contents in the file. If so
(and remember that this is mere unsupported speculation) then that would be a
/gross/ deficiency in the Notes implementation. Gross to the point of
irresponsibility, IMO -- which is as good a reason as any to guess that this is
not, in fact, the source of the problem ;-)

Still, unlikely though it may be, it's easy enough to test. This little Java
program creates two ZIPs in the current directory, one has the size/crc
preceding the contents of the single entry; the other is identical except that
the size/crc follows the contents. If Notes can read one but not then other,
then the problem is definitely in Notes.

-- chris

=============================
import java.util.zip.*;
import java.io.*;

public class Enzip
{
public static void
main(String[] args)
throws Exception
{
// "hello world!" in utf-8"
byte[] contents = new byte[] {
0x68, 0x65, 0x6C, 0x6C, 0x6F,
0x20, 0x77, 0x6F, 0x72, 0x6C,
0x64, 0x21
};

// write a ZIP where size/crc data follows the contets
ZipOutputStream zos
= new ZipOutputStream(
new BufferedOutputStream(
new FileOutputStream(
"test-follows.zip")));
ZipEntry entry = new ZipEntry("hello.txt");
zos.putNextEntry(entry);
zos.write(contents);
zos.closeEntry();
zos.close();

// write a ZIP where size/crc data precedes the contets
zos
= new ZipOutputStream(
new BufferedOutputStream(
new FileOutputStream(
"test-precedes.zip")));
entry = new ZipEntry("hello.txt");

// I worked these out offline
// they are the only difference from the "follows" case
entry.setCrc(62177901L);
entry.setCompressedSize(14L);
entry.setSize(12);

zos.putNextEntry(entry);
zos.write(contents);
zos.closeEntry();
zos.close();
}
}
=============================