f



Lotus Notes Viewer not opening ZIP files created using Java

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.lang.java.programmer/browse_thread/thread/149e0cee77d443fa/4f874e0dc926fbc0?lnk=gst&q=lotus+notes+java+zip+view&rnum=1&hl=en#
__________________________________________________
Newsgroups: comp.lang.java.programmer
From: "rjb" <rjbl...@worldonline.nl>
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: p...@best.com (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

rjb <rjbl...@worldonline.nl> wrote:
 >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" <rjbl...@worldonline.nl>
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 <marcoschm...@geocities.com>
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
On Thu, 25 May 2000 17:04:27 +0200, "rjb" <rjbl...@worldonline.nl>
wrote:

 >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
0
3/6/2007 2:00:16 PM
comp.lang.java.programmer 52714 articles. 1 followers. Post Follow

2 Replies
552 Views

Similar Articles

[PageSpeed] 56

David Zwerlin wrote:> 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 anyway abnormal (and I've written a ZIP file decoder myself, so I do know a littleabout the subject).   I'd guess that it's a bug in Notes.However, without further information -- which can only come from the Notesdevelopers -- I don't see how anyone in the Java world can do more thanspeculate.So the rest of this post is mere speculation...My /guess/ (and it is only a guess) is that the problem comes somewhere asNotes attempts to find the "central directory" in the ZIP file.  The logic fordoing that involves starting at the end of the file and scanning backwardslooking for a specific bit-pattern, it is then necessary (if you wantreliability) to use some heuristics to check that the data you find immediatelyafter 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 invalidassumptions) then I can imagine it rejecting Java-generated ZIPs incorrectly.Another possibility --- remote -- is that something in the data transfer chainis changing the ZIP file in a way that causes Notes to reject it (presumablythe Java-generated ZIPs reach the users via a different route from your testZIPs created with different tools).  For instance I recently came across a casewhere 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 tochange) checks that the data /after/ the bit-pattern should reach exactly up tothe end of the file -- so random data stuck on the end causes it (correctly,IMO) to fail.    -- chris
0
Chris
3/6/2007 6:31:06 PM
[I meant to include this in my earlier post, but managed to press send whilethe edit window was still open on the later draft....]I wrote:> So the rest of this post is mere speculation...Another remote possibility is that Notes is unable to deal with ZIPs where anyentry'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 ofirresponsibility, IMO -- which is as good a reason as any to guess that this isnot, in fact, the source of the problem ;-)Still, unlikely though it may be, it's easy enough to test.  This little Javaprogram creates two ZIPs in the current directory, one has the size/crcpreceding the contents of the single entry; the other is identical except thatthe 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();    }}=============================
0
Chris
3/6/2007 7:58:45 PM
Reply: