APPIMAGE

Generated by scripts/gen-format-pages.py from docs/data/format-metadata/, FILE_FORMATS.csv and docs/formats-master.csv. Do not edit by hand: change the source, then run the script.

AppImage Preview.

At a glance

How much Poka reads

B4 Summary. The container and metadata are read and summarised (counts, properties, structure), but the main content is not rendered.

Confidence: medium (the reviewer read the code). Basis: Reviewed 2026-10-26: read parsers/poka-appimage/src/main.rs (479 lines) and plugin.json. Four unit tests cover the type detection and SquashFS search; the corpus has no AppImage. Covers .AppImage. The card reads the ELF architecture and AppImage type (1 or 2), finds the SquashFS superblock after the runtime and shows its offset, version, compression, inode count, block size, size used and build time. Judgement: B4: the bundle's structure and file-system header are read, but the files inside are not.

What Poka does not read

• The SquashFS file system is not walked: no file list, desktop entry, icon or AppRun
• Type 1 AppImages (ISO 9660) are recognised but not read further
• The embedded signature and update information are not read
• Only the first 8 MiB is read, so a SquashFS that starts later is not found (flagged)

Libraries

Libraries Poka uses or has assessed for this format, with the status, licence and language the registry records.

• squishy (squishy-cli) (candidate; MIT; Rust; https://github.com/pkgforge/squishy) — CLI can extract icon, desktop entry and AppStream metadata from an AppImage, finding the offset automatically; library reads SquashFS and DwarFS
• squashfs_reader (candidate; MIT OR Apache-2.0; Rust; https://docs.rs/squashfs_reader) — Generic pure-Rust read-only SquashFS reader; the AppImage offset must be located separately

Sources

• parsers/poka-appimage/src/main.rs
• parsers/poka-appimage/plugin.json