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. Proposed fix: - do not recompress binary file that are gz type (type determined using the "file" command) or - 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)... 94.100.119.165 Connecting to bugs.gentoo.org (bugs.gentoo.org)|94.100.119.165|: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: openoffice@gentoo.org Bugzilla itself doesn't even compress any data as far as I know.
