probably related to gzip'ed compressions algorithm Reproducible: Always Steps to Reproduce: 1.ark /var/log/portage/app-emulation:libvirt-1.0.0:20121110-231620.log.gz 2.clicked onto the file name app-emulation:libvirt-1.0.0:20121110-231620.log 3. Actual Results: only first 4 lines are displayed Expected Results: all lines should be shown $ zcat /var/log/portage/app-emulation:libvirt-1.0.0:20121110-231620.log.gz | wc 3142 12968 157737 re-gezipping works : https://bugs.gentoo.org/show_bug.cgi?id=443948
A Gentoo dev's opinion is : > "Wouldn't it be app-arch/libarchive that is at fault here?"
(In reply to comment #1) > A Gentoo dev's opinion is : > > "Wouldn't it be app-arch/libarchive that is at fault here?" Nope, libarchive would have been used if this was a tar.gz file; for .gz archives KDE's KGZipFilter is used instead. This reminds me a lot of bug 232843, related to multi-member gzip files. However, contrary to the attachment from bug 241153, both archives attached to the Gentoo bug report seem to be gzipped files inside gzipped files. GNU gunzip on ArchLinux happily extracted them into plain-text files, however both my FreeBSD gunzip and 7zip have extracted them into the original .gz file which can then be extracted into the plain-text file. The fact KGZipFilter behaves even more differently than the other tools is also surprising. Do you know how this file is generated (whether it is generated by GNU gzip, or by some Python tool etc)?
Can not reproduce issues with .gz files, use that often with Kate.