[
https://issues.apache.org/jira/browse/FILEUPLOAD-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594692#action_12594692
]
F. Andy Seidl commented on FILEUPLOAD-149:
------------------------------------------
Hi All,
I'm back to debugging this FileUpload corruption issue. I've just installed
commons-fileupload-1.2.1 and commons-io-1.4 and ran a simple test...
I started with a local .jpg image, fileupload-test.jpg, and created two copies
of that file: fileupload-test-copy.jpg and fileupload-test-copy-2.jpg. I
uploaded the first two using FileUpload here:
http://faseidl.com/docs/fileupload-test.jpg
http://faseidl.com/docs/fileupload-test-copy.jpg
I FTP-ed the third file here:
http://faseidl.com/docs/fileupload-test-copy-2.jpg
As you can see, the FileUpload-ed files are corrupted while the FTP-ed file is
not.
This situation occurs on five different servers while things work great on six
others. All hypotheses welcome.
> Intermittent file corruption on upload
> --------------------------------------
>
> Key: FILEUPLOAD-149
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-149
> Project: Commons FileUpload
> Issue Type: Bug
> Affects Versions: 1.2
> Environment: Linux (CentOS) server; all client platforms and browsers
> Reporter: F. Andy Seidl
> Priority: Critical
>
> I have been struggling for several weeks trying to track down the root cause
> of a sporadic file corruption problem using File Upload. I'm really stumped
> at this point and welcome any suggestions as to avenues of debugging
> pursuit.
> Here's overview of the problem:
> I have eight Linux (CentOS) servers all running the same web application--a
> set of Java servlets using Resin as a servlet runner under Apache. All
> servers were configured using the same script that installs jars,
> config files, etc.
> On three of the servers, File Upload works reliably. On five of the
> servers, File Upload usually (but not always) leaves me with a corrupted file.
> Corrupted files are always the correct length but contain a relatively small
> percentage of scrambled bytes. I looked for obvious patterns like newlines
> being altered or high-bit bytes being converted to or from UTF-8, but there
> is no obvious (to me, anyway) pattern in the failure.
> I have also tested with IE, FireFox, and Safari on both Windows and MacOS.
> The issue appears to be independent of client browser and OS.
> Looking at Java system properties, I notice that while the classpath and
> bootclasspath have the same jars lists on all servers, they are not listed
> in the same order (probably listed in directory order as the paths are
> constructed by a script that inspects lib directories.)
> Is anyone aware of classpath order dependencies that could break File
> Upload?
> Can anyone offer any suggestions about what *might* be breaking File Upload?
> Or what other questions I should be asking? At the moment, I'm feeling
> rather stumped.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
