Fails with InvalidMagicBytes when AppImageLauncher is installed

d1vanov commented 4 years ago

Select your issue type: (check at least one)

[x] Bug
[ ] Question
[ ] Suggestion
[ ] Other (please describe):

Describe your issue: I've been trying to use this library in my project to enable checking for AppImage updates and installing them from within the app. It works well in general but recently I found out that checking for updates functionality breaks when AppImageLauncher is installed.

AppImageLauncher is a project aiming to provide better integration of AppImages into the Linux desktop. I don't know in details how it works but it seems like it registers an interpreter for AppImage file type and hence gets the ability to intercept their launches. For example, when you try to launch some AppImage downloaded from the Internet, AppImageLauncher asks you whether you want to integrate this AppImage into the system (i.e. move it to ~/Applications) or just run it. Another thing that AppImageLauncher seems to be doing is changing the actual path to the AppImage from the application's POV: when AppImageDeltaRevisioner object is constructed without arguments, the path to AppImage it guesses automatically is not the actual path to the AppImage file but something like this instead:

/run/user/1000/appimagelauncherfs/0001.AppImage

I don't quite know what this executable is but it doesn't seem to be an actual AppImage. At least it doesn't contain A and I bytes which AppImageUpdaterBridge expects to be in place. For the actuall AppImage of my app I do see these bytes in place:

$ head -n 1 Quentier-x86_64_ef0106efad9cea0824a19d60aef4af2e.AppImage 
ELFAI>�F@@(�@@ @@@@@ <...>

For this executable I don't:

$ head -n 1 /run/user/1000/appimagelauncherfs/0001.AppImage
ELF>�F@@(�@@ @@@@@ <...>

So it's no surprise that check for magic bytes fails.

It's not immediately clear how AppImageUpdaterBridge can be adapted to AppImageLauncher presence. Perhaps some research is required first to figure out what exactly AppImageLauncher does to the actual AppImages when they are launched. Then AppImageUpdaterBridge could be able to detect that AppImageLauncher is installed (for example, looking at whether AppImageLauncher executable is within PATH) and act accordingly i.e. find some other way to figure out AppImage's type.

Ways to Reproduce the issue (optional): Install AppImageLauncher, take any executable using this library and try to check for updates.

d1vanov commented 4 years ago

And one more not quite related thing: I've been looking into the source code around the checks for magic bytes and found this if condition:

    if (magicBytes[0] != 'A' && magicBytes[1] != 'I') {
        /*
         * If its not an AppImage then lets check if its a linux desktop file , If so then parse the 'Exec'
         * to find the actual AppImage.
        */

It seems to be that the condition should be logical or instead of logical and:

    if (magicBytes[0] != 'A' || magicBytes[1] != 'I') {

Otherwise if at least one of these two magic bytes matches the expected one, the body of if condition won't be entered although it should be.