Created attachment 602480 [details] Sample tarball I used Description of problem: It seems to me that TCMS modifies tarball (attachment) after uploaded. $ md5sum eclipse-show-gcc-version.tar.gz* 3b7951f5f5c09c1f092725c0b7e1c5a9 eclipse-show-gcc-version.tar.gz (Original file) fd5695b75c6f1ae247427aeabf198b20 eclipse-show-gcc-version.tar.gz_upload (Uploaded and then downloaded from TCMS) Also: $ file eclipse-show-gcc-version.tar.gz* eclipse-show-gcc-version.tar.gz: gzip compressed data, from Unix, last modified: Mon Aug 6 12:28:30 2012 eclipse-show-gcc-version.tar.gz_upload: gzip compressed data, from Unix And: $ ll eclipse-show-gcc-version.tar.gz* -rw-rw-r--. 1 newman newman 2590 Aug 6 12:28 eclipse-show-gcc-version.tar.gz -rw-rw-r--. 1 newman newman 2620 Aug 6 12:37 eclipse-show-gcc-version.tar.gz_upload Version-Release number of selected component (if applicable): https://tcms.engineering.redhat.com/case/191019/attachment/ How reproducible: always Expected results: Don't modify uploaded attachments in any way.
Some longer time ago I saw a similar behaviour with bugzilla. The workaround was to separately ungzip and after that untar: Download link for clknetsim.tar.gz see https://bugzilla.redhat.com/show_bug.cgi?id=654011#c0 [root@a6 tmp.uMFrrb2QQO]# tar xvf clknetsim.tar.gz tar: This does not look like a tar archive tar: Skipping to next header tar: Exiting with failure status due to previous errors [root@a6 tmp.uMFrrb2QQO]# ls clknetsim.tar.gz ntptestsuite.tar.gz [root@a6 tmp.uMFrrb2QQO]# gunzip clknetsim.tar.gz [root@a6 tmp.uMFrrb2QQO]# tar xf clknetsim.tar [root@a6 tmp.uMFrrb2QQO]# ls clknetsim clknetsim.tar ntptestsuite.tar.gz [root@a6 tmp.uMFrrb2QQO]# This workaround is applicable also in this case. That time I discussed this with ovasik, but I don't have related irc log any more. CCying Ondrej. Be aware that this may be a completely different case.
Actually - it was not workaround - the issue if I remember correctly was in double gzipped archive - tar is able to recognize only once gzipped archive. It seems to be the same case now.
OK. `gunzip & tar xf` instead of simple `tar xf` works but still this is not what I uploaded to TCMS. I'd appreciate a comment from TCMS devs.
(In reply to comment #3) > OK. `gunzip & tar xf` instead of simple `tar xf` works but still this is not > what I uploaded to TCMS. > > I'd appreciate a comment from TCMS devs. the issue was in double gzipped archive - tar is able to recognize only once gzipped archive. TCMS web servers can compress files in gzip formate before them for download which cause double gzip.
This feature needs more efforts, and buzilla couldn't support it either. We considered to implement it later.
Did this problem happen again, recently? I tested with latest code by uploading and downloading several tarballs including your attachment. Not reproduce.
(In reply to jianchen from comment #5) > (In reply to comment #3) > > OK. `gunzip & tar xf` instead of simple `tar xf` works but still this is not > > what I uploaded to TCMS. > > > > I'd appreciate a comment from TCMS devs. > the issue was in double gzipped archive - tar is able to recognize only once > gzipped archive. TCMS web servers can compress files in gzip formate before > them for download which cause double gzip. AddOutputFilterByType is deprecated after Apache 2.0. It seems AddOutputFilterByType does not take effect on those given mime-types only.
verify on qa server with 3.8.11: TCMS don't break up the uploaded attachments for now.The attachments can work well after downloading from the nitrate.