Bug 329579 - Extracted file is corrupt
Summary: Extracted file is corrupt
Status: RESOLVED FIXED
Alias: None
Product: frameworks-karchive
Classification: Frameworks and Libraries
Component: general (other bugs)
Version First Reported In: 5.51.0
Platform: openSUSE Linux
: NOR major
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-03 21:37 UTC by Fabian Vogt
Modified: 2025-04-16 15:34 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Vogt 2014-01-03 21:37:13 UTC
The TI nspire OS files are valid zip files and can be extracted by any zip utility such as unzip. But if I copy-paste zip:/file.zip/boot2.img to extract it, the resulting uncompressed file is corrupt. There is additional stuff at the beginning and at the end.
Example download: http://education.ti.com/de/deutschland/software/details/en/0607F21D07B14ACB9EE85E57A9C30EDA/ti-nspirecxcas_os

Reproducible: Always

Steps to Reproduce:
1. Download http://education.ti.com/de/deutschland/software/details/en/0607F21D07B14ACB9EE85E57A9C30EDA/ti-nspirecxcas_os
2. Open in dolphin with zip:/
3. Copy boot2.img
4. Compare with the result of "unzip *.tcc boot2.img"
5. The files differ



Ark works (as expected).
"unzip" says "63 extra bytes at beginning or within zipfile".
Maybe it's an issue that the header isn't word-aligned?
Comment 1 Julian Steinmann 2018-07-22 16:44:33 UTC
I can reproduce this behavior using KDE Frameworks 5.48, relocating to kio-extras.
Comment 2 David Faure 2018-08-01 08:20:28 UTC
Probably a KArchive bug though ;)
Comment 3 Bug Janitor Service 2025-04-02 16:02:45 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/karchive/-/merge_requests/111
Comment 4 Stefan Brüns 2025-04-16 15:34:00 UTC
Git commit e20f869437fc4dd979e36e8f18403a03920b148e by Stefan Brüns.
Committed on 16/04/2025 at 15:31.
Pushed by bruns into branch 'master'.

kzip: Fix position calculation for archives with prepended arbitrary data

There are two variants of non-ZIP data before the first Local File Header.
Either with offset in the Central Directory reflecting the actual
position, i.e. the first entry offset in the CD will point just after the
additional non-ZIP header instead of 0. This is the case for e.g.
self-extracting archives from WinZIP.

The other is just a concatenation of non-ZIP data and a regular ZIP file,
i.e. the first entry in the CD will contain an offset value of 0.

unzip (Info-ZIP) and bsdunzip (libarchive) accept both variants (unzip -v
provides a warning - "warning [xxx.zip]:  61 extra bytes at beginning or
within zipfile"), libzip requires an explicit offset (-o 61) for the
latter.

Verify if the (adjusted) local file header offset in the Central
Directory match the seen positions, bail out otherwise. Provide a
warning similar to unzip in case there is extra data.

Limit the initial header search to the first 4 MByte (previously
unlimited). Also provide a more specific error message.

M  +26   -0    autotests/karchivetest.cpp
M  +1    -0    autotests/karchivetest.h
M  +27   -4    src/kzip.cpp

https://invent.kde.org/frameworks/karchive/-/commit/e20f869437fc4dd979e36e8f18403a03920b148e