If an attachment is read from a msg file via the getAttachmentFiles() of the MapiMessage class and streamed to a file, the result will be a file with even length and lots of zeros in the end. For example a PDF file ends with %%EOF{CR}, but the attachment from the msg show in an editor: %%EOF{CR}{NUL}{NUL}{NUL}{NUL}{NUL}{NUL}{NUL}{NUL}{NUL}{NUL}{NUL}. Just compare the original files that were put into the msg and the result of the getAttachmentFiles() method using a diff tool and you will see. Outlook extracts the attachments correctly by the way, it seems to know the exact length of the files.
Can you upload a sample .msg file with an attachment that displays this behaviour? We'll want to use that so we have something to test a fix against
Created attachment 24690 [details] Test files as zip, contains msg and attachments before and after processing My sample code: MAPIMessage mapiMsg = new MAPIMessage( new FileInputStream( new File("plain.msg") ) ); Map<String, ByteArrayInputStream> atts = mapiMsg.getAttachmentFiles(); if( atts != null && atts.size() == 1 ) { String attName = atts.keySet().iterator().next(); ByteArrayInputStream att = atts.get( attName ); FileUtils.stream( att, new FileOutputStream( new File("after.txt") ) ); }
Please do keep looking for a file that displays this problem, and which you can share. Without the message to investigate, there's unfortunately nothing we can do to fix it.
I tried again with the newer revision 898295 (Jan 12 2010) and it seems to work now for me, but you and me should keep an eye on it :-)