For example, in bug 336510 (but i had the issue in a few other bugs). The reporter want to attach a big build log; it's too big, so, the reporter compresse it: ooo.log became ooo.log.gz .
For a reason i could imagine, bugzilla compresses the incoming binary file, after it's uploaded on server. I have never uploaded any binary, so i don't know if it does it everytime.
The problem is that, when we download the file, a first gunzip uncompresses the work of bugzilla, and renames the file to ooo.log. So, we now have a compressed file, called without .gz.
- do not recompress binary file that are gz type (type determined using the "file" command)
- after bugzilla runs gunzip, check that the file name have been changed, and that it's been extended, so that, in our case, ooo.log.gz would become ooo.log.gz.gz .
Generally speaking, it happens often on OOo bugs :) it seems to be the only app that generate big enough logs to make this issue happen.
Use the correct mime-type and it should work, in this case "application/x-compressed-tar".
You can even use the auto-detect option when adding an attachment if your browser is able to properly identify the mime-type.
# wget 'https://bugs.gentoo.org/attachment.cgi?id=247541' -O test.gz
--2011-03-09 18:34:35-- https://bugs.gentoo.org/attachment.cgi?id=247541
Resolving bugs.gentoo.org (bugs.gentoo.org)... 126.96.36.199
Connecting to bugs.gentoo.org (bugs.gentoo.org)|188.8.131.52|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 235677 (230K) [application/x-gzip]
Saving to: `test.gz'
100%[======================================>] 235,677 388K/s in 0.6s
2011-03-09 18:34:37 (388 KB/s) - `test.gz' saved [235677/235677]
# file test.gz
test.gz: gzip compressed data, was "build.log", from Unix, last modified: Wed Sep 15 04:24:25 2010, max compressio
# gunzip test.gz
# head -n 3 test
* CPV: app-office/openoffice-3.2.1
* REPO: gentoo
* Maintainer: email@example.com
Bugzilla itself doesn't even compress any data as far as I know.