| Summary: | Ark creates strange .tar.gz archives. | ||
|---|---|---|---|
| Product: | [Applications] ark | Reporter: | Jekyll Wu <adaptee> |
| Component: | general | Assignee: | Raphael Kubo da Costa <rakuco> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | plusfabi |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | 4.8.0 | |
| Sentry Crash Report: | |||
| Attachments: |
A simple file for reproducing
Another simple file which shows slightly different 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
|
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.