Can amiberry test for whdload.lha archives, before trying to load any.lha archive? (automate filetype associations)

[giantclambake]

As discussed, associating amiberry with the .lha mime-type, results in any archive.lha file being actioned with "Open with amiberry".... regardless of whether the .lha is a whdload gamepak or not. As mentioned, the links2 console based web-browser, was able to differentiate that a whdload.lha was mime-type x-lzh-compressed and all other archive.lha files as x-lha-archive.

Digging deeper, the third through seventh bytes of the compressed file, identify the archive compression method as type -lha5-
The eighth byte I am unsure of...

However, for the ninth through twelfth bytes of the compressed archive, are unique to whdload.lha files -- 01 00 00 84

Is there any way amiberry can test for this signature, before attempting to load (or being fed) any *.lha file?

TIA

[midwan]

I think that goes a bit out of scope.
The .lha filetype should probably not be associated with Amiberry in the first place. It can handle .lha based (or even .zip based) WHDLoad packs, but maybe that should be handled in another way (Open With... ?)

[giantclambake]

For sure, it'd be a good idea to remove application/x-lha from the MIMETYPE then to avoid the inevitable.

It does leave the user free to RMB-> Open with amiberry ....beyond that point it begets a semantic debate, as often the choice of 'Always open the same type of files..' can make the decision tricky..... because the reality is a whdload.lha gamepack, is a uniquely different type of file to that of some archive.lha that isn't a whdload gamepack ....sigh 8)

...there's also two layers here... what a browser app does opening this filetype, and what the WM in use does handling the same thing...ie; without the mimetype, no double-click...

I agree however, as mentioned ~ if links2 can detect the pattern and return that flag, other browser apps (and WMs) should be doing something similar.

Thanks ;)

[giantclambake]

After some investigation and reading, it would appear this is 'our problem' so to speak -- the position wrt the handling of .lha files, is a good example as it turns out..

citing: https://specifications.freedesktop.org/shared-mime-info-spec/latest/ar01s02.html#id-1.3.19

"The type determined in this way is only a guess, and an application MUST NOT trust a file based simply on its MIME type. For example, a downloader should not pass a file directly to a launcher application without confirmation simply because the type looks `harmless' (eg, text/plain)."

So at best currently, we can only use mime-type detection as being 'hints'... the rest is up to us ;)

The progression above (although it does specify downloader, also consider doubleclick on desktop icon)...

*the System mode of shared-mime-info correctly identifies the <file> as application/x-lha
*the firefox browser downloader (or desktop icon launch), inherits the System mode determination of <file> type
**in the links2 browser case, the downloader accepts the -lh5- <file> type, and then determines what kind of .lha it is
***links2 resolves <file> to mime-type application/x-lzh-compressed, and you can assign amiberry as the default handler, and actions pertaining to application/x-lha handling are unaffected.

It could be said, firefox isn't following the 'standards' here ; links2 is ;) However, by the same token, herein lies the lesson example, of why we can't trust System mode and blindly accept files, just because shared-mime-info says so...

In a so called 'perfect world', amiberry should have a 'file-loader' to check the veracity of the file.ext it's being asked to handle, and if the <file> doesn't match the extension type criteria, amiberry should issue an "Error: unknown file type" message and gracefully bail (in X you'd have a popup message window, click on OK to quit 8).... the lean on all this is about security, and it's easy to imagine why that's pertinent ;)

...the next level down, is by leveraging the share-mime-info system itself, as fs-uae does by including the /usr/share/mime/packages/fs-uae.xml file. In this file, can be assigned mime-type handling, which is added to the mime.cache when update-mime-database is run.... these can apply systemwide (System mode), or defined in user's XDG_HOME (typically ~/.local/share/mime/* )

The things that I noted could be added here, are detection of .ipf & .dms images (these are currently undefined), and being able to detect .lha <file> type using the shared-mime-info system.

I can puddle about with this mime stuff if you like?

[giantclambake]

Brief: The .ipf & .dms floppy image filetypes are untested by shared-mime-info, and of type 'unknown' -- on my advice, we added application/octet-stream to the Amiberry.desktop file, which in turn promotes amiberry to be a 'Recommended' application for this filetype, but it is only deduced by file extension. This is fraught with danger, in that any file with the .ipf or .dms extension will be loaded (by amiberry) unchecked. Also, the user ..if desired ... has to manually set the default app for these extensions....

...application/x-lha is a problem child, in that normal archive.lha files are also aliased to application/x-lzh-compressed, and the shared-mime-info system only tests for the lha compression. The whdload.lha files from ie; Retroplay repo, differ in significant ways, as illustrated by the use of the file command...

file RodLand_v1.4_1509.lha
RodLand_v1.4_1509.lha: LHa (2.x) archive data [lh5], 'A' OS, with "RodLand.info" //whdload lha archive

file Picasso96.lha
Picasso96.lha: LHa (2.x) archive data [lh5], with "Picasso96Install.info" //normal lha archive - note missing 'A' OS bits

I believe the alias to application/x-lzh-compressed is in somehow related to the glob value "*.lzh" for file extension that will be considered as application/x-lha as well as "*.lha".

In any event, applications should NOT trust mime-type detection at a System mode level anyway, however application specific mime-types are allowed, so that one can add to/extend the base shared-mime-info structure, to suit the application needs...(this is the 'free' part of freedesktop standards ;) This is considered 'safe' practice, and a multitude of (linux) applications, employ this system in exactly the same way as described below (following their examples =).

Proposed: The following changes, achieves ....

*creates the mime-type application/x-SPS-virtual-media-image by testing .ipf files, and checking if the 'CAPS' string is present at the beginning of the file --> if so, amiberry is set as the default handler for this file type

*creates the mime-type application/x-DMS-compressed-disk-image by testing .dms files, and checking if the 'DMS!' string is present at the beginning of the file --> if so, amiberry is set as the default handler for this file type

*creates the mime-type application/x-WHDLoad-game-archive type by testing .lha files, and checking if the 4byte value 01000084 is present between the 9th thru 12th bytes (inclusive) of the file --> if so, amiberry is set as the default handler for this file type. In this way, the default handler for application/x-lha remains unchanged, and opening non-whdload.lha archive files works as normal. (the glob-deleteall & magic-deleteall directives achieve this)...

..for /usr/share/mime/packages/amiberry.xml

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
   <mime-type type="application/x-SPS-virtual-media-image">
     <comment>Interchangeable Preservation Format</comment>
     <generic-icon name="media-floppy"/>
     <magic priority="50">
     <match type="string" value="CAPS" offset="0"/>
     </magic>
     <glob pattern="*.ipf"/>
   </mime-type>
   <mime-type type="application/x-DMS-compressed-disk-image">
     <comment>Disk Masher System</comment>
     <generic-icon name="media-floppy"/>
     <magic priority="50">
     <match type="string" value="DMS!" offset="0"/>
     </magic>
     <glob pattern="*.dms"/>
   </mime-type>
   <mime-type type="application/x-WHDLoad-game-archive">
     <comment>WHDLoad Amiga Package</comment>
     <generic-icon name="package-x-generic"/>
     <magic-deleteall/>
     <magic priority="60">
     <match type="big32" value="0x001000084" offset="8:11"/>
     </magic>
     <glob-deleteall/>
     <glob pattern="*.lha"/>
   </mime-type>
</mime-info>

...for /usr/share/applications/Amiberry.desktop

[Desktop Entry]

# The type of the Desktop Entry, usually Application
Type = Application

# The version of the Desktop Entry specification to which this file complies
Version = 1.0

# The name of the application
Name = Amiberry

GenericName = Amiga Emulator

# A comment which can/will be used as a tooltip
Comment = Optimized Amiga Emulator

# The executable of the application, possibly with arguments
Exec = /usr/bin/amiberry %f
TryExec = /usr/bin/amiberry

# The name of the icon that will be used to display this entry
Icon = amiberry

# Describes whether this application needs to be run in a terminal or not
Terminal = false

# Describes the categories in which this entry should be shown
Categories = Game;Emulator;

MimeType=application/x-SPS-virtual-media-image;application/x-DMS-compressed-disk-image;application/x-amiga-disk-image;application/x-cue;application/x-WHDLoad-game-archive;

# Describes the encoding for the desktop entry
Encoding=UTF-8

Notes:

I've left x-SPS-virtual-media-image defined by the glob .ipf --- are there any other CAPS/SPS image type extensions that can be added here? (will work with all floppy images containing the CAPS header)

The icon choices for the floppy disk image files should work on any linux distro...I think ... needs to be checked -- OS will default to something else if icon file not found, nothing goes boom.

To test -- as root, copy the attached files into /usr/share/mime/packages/amiberry.xml & /usr/share/applications/Amiberry.desktop and issue the commands update-desktop-database && update-mime-database /usr/share/mime You should then be able to doubleclick or Open these filetypes, with amiberry as the default handler. Doing the same thing with a non-whdload.lha should open ark/xarchiver/whatever application is default for handling LHA archives.

Seems good here, let me know if any problems exist (works here in Bookworm & Puppy 10)

TIA
amiberry.xml.gz
Amiberry.desktop.gz