Bug 363209

Summary:	Allow browsing AppImage images
Product:	[Applications] ark	Reporter:	Nicolas F. <kdebugs>
Component:	plugins	Assignee:	Ragnar Thomsen <rthomsen6>
Status:	RESOLVED FIXED
Severity:	wishlist	CC:	elvis.angelaccio, probono, rakuco, rthomsen6
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:	http://commits.kde.org/ark/bf2de67e185f042165cd17b8b8996fae0cc97381	Version Fixed/Implemented In:	16.08.0
Sentry Crash Report:

Description Nicolas F. 2016-05-18 09:59:27 UTC

AppImage consist of an ELF embedded in the ISO9660 header which mounts the image, and the actual zisofs compressed data.

I do not think AppImage has its own mimetype, though the format should be easily identifiable considering it's essentially an ISO9660 with a special header.

Reproducible: Always

Comment 1 Elvis Angelaccio 2016-05-18 12:04:42 UTC

Uhm , I just renamed an .appimage file to .iso and Ark opened it just fine, though it would be nice if Ark could open it automagically.

Comment 2 probono 2016-05-19 06:38:13 UTC

Let's rephrase this as:
Even when an ISO file is renamed, it should still be possible to be processed by ark.
To determine whether a file is an ISO, it could check for the "CD001" magic.

Comment 3 Ragnar Thomsen 2016-05-19 09:34:18 UTC

According to https://bugs.freedesktop.org/show_bug.cgi?id=10049 the developers of shared-mime-info decided not to add magic byte for the application/x-cd-image mimetype due to the magic byte being too far in the file. Hence detection of mimetype by content is not possible for ISO images.
We don't want to start parsing magic bytes ourselves in Ark, but we can add a custom mimetype for the .AppImage filename extension.

Comment 4 Elvis Angelaccio 2016-05-20 10:05:24 UTC

Ragnar, see also: https://github.com/probonopd/AppImageKit/issues/144

Comment 5 Elvis Angelaccio 2016-06-27 21:46:54 UTC

AppImage now has its own mimetype in shared-mime-info [1].

However, after manually installing the mimetype [2], Ark still doesn't open/extract AppImage files.
This is because Ark checks whether "application/x-iso9660-appimage" inherits from "application/x-cd-image" (which is one of the mimetypes Ark is registered with), but suprisingly this doesn't work: the appimage mimetype inherits from "application/x-iso9660-image" (alias of "application/x-cd-image"). Unfortunately QMimeType doesn't like aliases and "resolves" them to their actual mimetype ("application/x-cd-image" in this case).

This looks to me like a limitation in the Qt api, but we could workaround it in some way:

1. By checking also the aliases of our registered mimetypes, or
2. By making the AppImage mime inherit from "application/x-cd-image"

1. should be doable but 2. could be a cleaner solution...

[1]: https://cgit.freedesktop.org/xdg/shared-mime-info/commit/?id=01fa61fc002afdcf43f61e7df2d6cc6f6968d8d2
[2]: https://github.com/probonopd/AppImageKit/issues/144#issuecomment-227015057

Comment 6 Ragnar Thomsen 2016-07-20 17:54:18 UTC

Git commit bf2de67e185f042165cd17b8b8996fae0cc97381 by Ragnar Thomsen.
Committed on 20/07/2016 at 17:47.
Pushed by rthomsen into branch 'Applications/16.08'.

Add support for AppImage

AppImages are both executables and ISO images and can be handled by
libarchive. Support for opening AppImages was enabled in the
libarchiveplugin. The mimetype for AppImage has been committed to
shared-mime-info, but has not yet been released. We therefore install a
custom mimetype for AppImage.

Test cases for this mimetype were added to MimeTypeTest and ArchiveTest.
FIXED-IN: 16.08.0
Differential Revision: D2226

M  +14   -1    autotests/kerfuffle/archivetest.cpp
A  +-    --    autotests/kerfuffle/data/hello-2.8-x86_64.AppImage
M  +2    -0    autotests/kerfuffle/mimetypetest.cpp
M  +17   -0    kerfuffle/mime/kerfuffle.xml
M  +3    -2    plugins/libarchive/CMakeLists.txt

http://commits.kde.org/ark/bf2de67e185f042165cd17b8b8996fae0cc97381