• Contact Project
POP CFC Issue: parseBodyPart() Can Corrupt Email Attachments
||parseBodyPart() Can Corrupt Email Attachments
||07/16/13 5:52 AM
||07/24/13 5:18 AM
parseBodyPart() appears to be writing an extra byte to the end of some attachments when it saves them (it seems to be writing a -1?). This is most evident when retrieving an email with an XLSX attachment because when opened it will say that the file is corrupt.
Also, if an email has an XLSX document and a TXT file attached, the TXT file will be saved empty. The following change has resolved both of these
issue in my case. This replaced the first try/catch in the parseBodyPart() function.
<cfset bodyPartInputStream = arguments.bodyPart.getContent()>
<!--- If bodyPartInputStream is a string from a text file (instead of an object) then write its bytes. --->
<cfloop condition="bodyPartInputStream.available() GT -1">
<cfset fileLine = bodyPartInputStream.read()>
<!--- Do not write the final "-1" of this loop to files. --->
<cfif fileLine neq -1>
<!--- For CF8 and below we need to catch and ignore this error so we can close the streams --->
<!--- For CF9 we should use a finally block to force the .close() calls --->
Created by hjcotton (Hadyn Cotton) : 07/16/13 5:52 AM
Comment by hjcotton (Hadyn Cotton) : 07/16/13 6:00 AM
It is probably worth noting that I'm using: POPCFC.parseRawMessage(POPCFC.GetRawMessageByUID(messageID)) to arrive at this situation.
Updated by newmediadev (Paul Vernon) : 07/24/13 5:18 AM
The suggested code has been incorporated into the release.
To add a comment to this bug, please login using the link above.
Adobe and the Adobe product names are either registered trademarks or
trademarks of Adobe Systems Incorporated in the United States and/or other