Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <1209792426.1210133395911.JavaMail.jira@brutus>
Date: Tue, 6 May 2008 21:09:55 -0700 (PDT)
From: "F. Andy Seidl (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (FILEUPLOAD-149) Intermittent file corruption on
 upload
In-Reply-To: <10953473.1193244530599.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/FILEUPLOAD-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594768#action_12594768 ] 

F. Andy Seidl commented on FILEUPLOAD-149:
------------------------------------------

Very interesting results.  Does this trigger any ideas?

My code writes uploaded files do disk by direclty copying the FileItem's
input stream to the final file location.  As an experiment to rule out a
problem in the this copy operation, I createed a small (1112 byte) .jpg
image file named fu-0.jpg.  Then I created nine exact copies of the
file: fu-1.jpg, fu-2.jpg, ..., fu-9.jpg.

I FTP-ed fu-0.jpg to the server and I uploaded files 1-9 using
FileUpload in a single upload request with nine files attached in
numeric order.  All the files uploaded without error except files 4 and
5.

Here is where it gets interesting...

Look at the sizes of the uploaded files:

fu-0.jpg: 1112
fu-1.jpg: 1112
fu-2.jpg: 1112
fu-3.jpg: 1112
fu-4.jpg: 1155   <=== wrong size
fu-5.jpg: 1069   <=== wrong size
fu-6.jpg: 1112
fu-7.jpg: 1112
fu-8.jpg: 1112
fu-9.jpg: 1112

BUT... file 4 and 5 add up to 2224 bytes, which is exactly two times the
correct size of 1112 bytes.  Thus, a worthy hypothesis is that the code
that parsed the raw servlet request stream somehow missed the the
boundary between the 4th and 5th file items.

To rule out an alternate hypothesis that this was a random glitch
unrelated to recognizing item boundaries, I repeated the test with ten
new files, fu-a.jpg, fu-b.jpg, ..., fu-i.jpg.  But this time, instead
FileUpload-ing nine files at once, I FileUploaded each file separately.
In this case, all ten files uploaded without error.

> 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.