Created attachment 66878 [details] A simple file for reproducing Version: unspecified (using Devel) OS: Linux Ark creates strange .tar.gz archives. The created archives makes 'tar' command complains, and can't be open directly in dolphin through kio. Reproducible: Didn't try Steps to Reproduce: 0. save the attachment as 'foo' 1. run "ark --changetofirstpath --add --autofilename tar.gz foo" to create a archive 2. run "tar -xzf foo.tar.gz" to extract it 3. invoke dolphin, try to open that generated foo.tar.gz archive directly through kio. Actual Results: tar complained: tar: Ignoring unknown extended header keyword `SCHILY.dev' tar: Ignoring unknown extended header keyword `SCHILY.ino' tar: Ignoring unknown extended header keyword `SCHILY.nlink' tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now dolphin failed to open that archive, complaining "Could not open the file, probably due to an unsupported file". Expected Results: tar command should extract that archive without complaining. dolphin should open and browser that archive directly through kio. I'm using Ark built from master code. Using Ark from KDE 4.7.x does not have this problem.
Created attachment 66879 [details] Another simple file which shows slightly different problem. Repeat above steps on this file. The slight difference is the archive can be opened in dolphin directly, but the structure is strange. It shows one extra folder named as "PaxHeader".
Hmmm, I just checked this again in Arch, Gentoo, and Fedora 16. The results are the same: Ark built from master code is broken. I'm using libarchive 2.8.5 on all those systems.
*** Bug 290203 has been marked as a duplicate of this bug. ***
This is weird. If I follow your steps in my FreeBSD system, it all works fine. If I build Ark in an ArchLinux machine, it fails as described. There have been absolutely no changes in the libarchive code between the v4.7.0 tag and master (modulo a change to make things build with QT_NO_CAST_FROM_ASCII)...
And now I was unable to reproduce this issue on another ArchLinux installation. The only pattern I can see is that Ark works fine on 64-bit installations, while it failed on a 32-bit OS. What architecture are you guys running on?
I'm using 32-bit OS.
Git commit 5149649d5388b570871f8579aaea1703136c9460 by Raphael Kubo da Costa. Committed on 05/01/2012 at 03:17. Pushed by rkcosta into branch 'KDE/4.8'. Add missing add_definition() calls. For some unknown reason, while the svn to git conversion work was going on in branches/work/kdeutils-build-standalone, the lines adding ${QT_DEFINITIONS} and ${KDE4_DEFINITIONS} to the definitions passed to the compiler end up not being included in each application's CMakeLists.txt. This was not a problem during the 4.7 series, as Dirk still packaged kdeutils as a single tarball, and the top-level CMakeLists.txt used did include these lines. The issue came to attention during the 4.8 beta/RC phase, when 32-bit Linux users had problems creating tarballs with Ark: libarchive is usually built in those systems with -D_FILE_OFFSET_BITS=64. This is set in KDE4_DEFINITIONS, which was not being used to build Ark. struct stat then had different sizes for Ark and libarchive, which caused all sorts of trouble. Packagers might want to look at this commit and the equivalent ones to the other affected kdeutils applications (filelight, kcalc, kcharselect, kdf, kfloppy, kgpg, kremotecontrol, ktimer, kwallet, superkaramba and sweeper) and apply them to their 4.8-RC packages. Sorry for the mess! FIXED-IN: 4.8.0 CCMAIL: release-team@kde.org CCMAIL: kde-packager@kde.org M +3 -0 CMakeLists.txt http://commits.kde.org/ark/5149649d5388b570871f8579aaea1703136c9460
Git commit 52ada1c890ee01a9aed22528f14bacb29aeb495c by Raphael Kubo da Costa. Committed on 05/01/2012 at 03:17. Pushed by rkcosta into branch 'master'. Add missing add_definition() calls. For some unknown reason, while the svn to git conversion work was going on in branches/work/kdeutils-build-standalone, the lines adding ${QT_DEFINITIONS} and ${KDE4_DEFINITIONS} to the definitions passed to the compiler end up not being included in each application's CMakeLists.txt. This was not a problem during the 4.7 series, as Dirk still packaged kdeutils as a single tarball, and the top-level CMakeLists.txt used did include these lines. The issue came to attention during the 4.8 beta/RC phase, when 32-bit Linux users had problems creating tarballs with Ark: libarchive is usually built in those systems with -D_FILE_OFFSET_BITS=64. This is set in KDE4_DEFINITIONS, which was not being used to build Ark. struct stat then had different sizes for Ark and libarchive, which caused all sorts of trouble. Packagers might want to look at this commit and the equivalent ones to the other affected kdeutils applications (filelight, kcalc, kcharselect, kdf, kfloppy, kgpg, kremotecontrol, ktimer, kwallet, superkaramba and sweeper) and apply them to their 4.8-RC packages. Sorry for the mess! FIXED-IN: 4.8.0 (cherry picked from commit 5149649d5388b570871f8579aaea1703136c9460) M +3 -0 CMakeLists.txt http://commits.kde.org/ark/52ada1c890ee01a9aed22528f14bacb29aeb495c