https://bugs.kde.org/show_bug.cgi?id=364071
Bug ID: 364071
Summary: assert when reading an unusual but valid Zip file
(entry named "/" and bad modes)
Product: frameworks-karchive
Version: 5.22.0
Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: fa...@kde.org
Reporter: j...@keelhaul.me.uk
CC: kdelibs-b...@kde.org
I have been sent a Zip archive produced by an unknown program, which has the
following listing:
$ zipinfo test.zip
Archive: test.zip
Zip file size: 202531733 bytes, number of entries: 2
?rwxr--r-- 2.0 unx 0 bl defN 14-Nov-16 18:39 /
?rwxr--r-- 2.0 unx 202630033 bl defN 14-Nov-15 22:50 G&M.MP4
2 files, 202630033 bytes uncompressed, 202531511 bytes compressed: 0.0%
$
The oddities are the unknown type of the two entries, and the first entry named
"/". Despite these, the zip command-line tools and Ark are able to read this
file and view/extract the contents. Unfortunately trying to view the file in
Dolphin, which attempts to enter the archive using the zip ioslave, crashes
with the status message "The process for the zip protocol died unexpectedly"
and the messages on stderr:
$ dolphin /var/tmp/test.zip
kio_archive(18001)/log_kio_archive ArchiveProtocol::checkNewFile: Need to open
a new file
kio_archive(18001)/log_kio_archive ArchiveProtocol::checkNewFile: the full path
is "/var/tmp/test.zip/"
kio_archive(18001)/log_kio_archive ArchiveProtocol::checkNewFile:
fullPath="/var/tmp/test.zip/" path=""
kio_archive(18001)/log_kio_archive ArchiveProtocol::checkNewFile: Found.
archiveFile="/var/tmp/test.zip" path="/"
kio_archive(18001)/log_kio_archive ArchiveProtocol::checkNewFile: Opening KZip
on "/var/tmp/test.zip"
kio_archive(18001)/default qt_assert: ASSERT: "access & S_IFDIR" in file
/ws/frameworks/tier1/karchive/src/kzip.cpp, line 702
kioslave: ####### CRASH ###### protocol = tar pid = 18001 signal = 6
Reproducible: Always
Steps to Reproduce:
Open the Zip file in Dolphin or Konqueror.
Actual Results:
Crash with messages as above.
Expected Results:
The spurious directory entry should either be handled or ignored.
I can make a similar Zip file (that exhibits the same problem) available if
needed, but the smallest example that I have is about 21Mb compressed and the
contents are personal.
--
You are receiving this mail because:
You are watching all bug changes.
