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)
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.
Comment 1•19 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•