I found an (ugly) workaround for this problem.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2503
Index: MultipartIterator.java
===================================================================
RCS file:
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/upload/MultipartIterator.java,v
retrieving revision 1.13.2.1
diff -c -2 -r1.13.2.1 MultipartIterator.java
*** MultipartIterator.java 2001/06/14 01:11:28 1.13.2.1
--- MultipartIterator.java 2001/08/06 18:53:06
***************
*** 34,40 ****
/**
! * The maximum size in bytes of the buffer used to read lines [4K]
*/
! public static int MAX_LINE_SIZE = 4096;
/**
--- 34,40 ----
/**
! * The maximum size in bytes of the buffer used to read lines [64K]
*/
! public static int MAX_LINE_SIZE = 65536;
/**
This isn't really a fix, as it just avoids the buggy codepath in
MultipartIterator.createLocalFile(). Here's the comment I put in our
local (hacked) version.
+ // The code for this cutCarriage and cutNewline
+ // mangles binary files where the "line length" is greater
+ // than the MAX_LINE_SIZE. Note that not all binary files
+ // have lines longer than MAX_LINE_SIZE -- most jpgs (for
+ // instance) consist of many small 'lines' of binary data,
+ // which avoids the cutXX codepath. Microsoft Excel
+ // spreadsheets, on the other hand, contain HUGE single line
+ // blobs of data (29k), triggering the strange cuts.
+ //
+ // http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2503
If someone a bit more parser-savvy could take a look at the block of
parser code that sniffs out newlines and tries to remove/add them, that
would be a real fix. Do you even need to do that for binary files?
Maybe curCarriage/cutNewline should be completely skipped for binary files..
-tak
