Closed Bug 307704 Opened 19 years ago Closed 19 years ago

Large Attachments Created As "Attachment #0", Not Actually Attached

Categories

(Bugzilla :: Attachments & Requests, defect)

x86
Linux
defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 141951

People

(Reporter: alex, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

This is occuring on Bugzilla 2.18.3, which is running on a RHEL ES Release 3
(Taroon Update 4) system, with Bugzilla tied to to MySQL 3.23.58.

For certain binary attachments, instead of simply attaching the file, Bugzilla
reports that changes have been submitted, but states that "Attachment #0" was
created. Upon returning to the bug to which the attachment was supposedly
attached, the attachment in question is not listed, and the comment noting its
creation has no link.

I believed at first that this was a size-related issue, since it appeared to be
happening only with files over 1MB. However, upon closer inspection, I've noted
that I was able to attach a 857,298-byte file, whereas I couldn't attach a
786,885 byte file. Additionally, the local Bugzilla administrator assures me
that our configuration allows attachments of unlimited size, and that the web
server on the Bugzilla box allows unlimited-size POSTs. I have been able to
personally verify that the MySQL variable max_allowed_packet is set to 1048576,
which should be large enough to allow my 786,885 byte file.

At this point I am not certain what is causing these files to be incorrectly
attached. As an explanation on the "Reproducibility" item, I am always able to
reproduce the issue once a problem file has been identified, but I cannot
correctly predict which files will cause problems.

It's worth noting that this is not a web browser issue, since I've seen
identical results using a Perl script with Bugzilla.pm and the browser whose
User-Agent string is above. Additionally, it is likely not a problem with the
specified Content-Type, as the problem persists irrespective of the use of
autodetect or manually selecting application/octet-stream.

Reproducible: Always

Steps to Reproduce:
1. Choose "Create a New Attachment" as usual.
2. Select the file to attach, and choose either autodetect or
manual->application/octet-stream.
3. Enter a standard description string (nothing fancy, not overly long or small).
4. Submit the attachment.

Actual Results:  
The standard "Changes Submitted" page is returned; instead of the attachment
being assigned a valid id, it comes back as "Attachment #0", and is not actually
attached to the bug.

Expected Results:  
Assigned a valid id to the attachment and actually attached it to the bug.

None, see Details above.
Theoretically max_allowed_packet should be 2 times the max attachment size you want to allow + 5KB or so. Some special characters in attachments have to be quoted. This can generate an > 1MB SQL command from an 786,885 byte file.

*** This bug has been marked as a duplicate of 141951 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.