Predictable mount points based on image path

[carragom]

Hi,
Trying to get multiple editions of Firefox running as AppImages. By editions I mean: firefox, firefox-esr and firefox-dev. This is proving tricky because of profile management.

AFAICT Firefox uses it's binary path to derive an installation ID see here. Based on this ID it reads the installs.ini file and looks for the default profile for this installation and finally reads the profiles.ini to determine the profile path.

As AppImages change the mount point every time they are executed a Firefox installation ID gets created every time the AppImage is executed and profile management becomes a nightmare.

In #83 constant mount points were dismissed for very good reasons. And I agree with that. Specially where software has hard-coded paths. But this is not the case with Firefox.

As a possible solution to this problem I think mount points could be derived from the AppImage path making the mount point constant for that specific AppImage file.

As an example having two copies of the same AppImage and a very dumb hashing function

• ~/Apps/firefox.appimage will always get mounted at /tmp/.mount_firefox-in-home-user-apps
• ~/Downloads/firefox.appimage will always get mounted at /tmp/.mount_firefox-in-home-user-downloads

I think this would solve the Firefox problem and possibly other apps that support multiple installations based on the binary path. But I'm not sure if this could break other things.

What do you think ?

[probonopd]

Looks like Firefox needs to learn that applications must work without being installed.

[carragom]

Thanks for the input about Firefox. Do you have any opinion about the actual idea/proposal ? Is it good ? Is it bad ? Why ?

[probonopd]

Application binaries being relocatable in the filesystem is important for the correct functioning an AppImage and the AppDir inside it. Applications should work correctly no matter where in the filesystem they reside. Applications not respecting this should be fixed. Most likely the respective application authors did not thing sufficiently about portable application bundles that can run from anywhere, so the topic should be brought to the application authors' attention. It needs to be clarified to the application authors that they should not assume the application to ever be "installed", as it is a perfectly valid use case to run applications, e.g., from removable media, network shares, etc.

(There is a very simple workaround that can be done in a custom AppRun script and requires no change on the part of the AppImage runtime, but I really don't want to give anyone bad ideas.)

References:

• Constant mount point, at least as option. #83
• https://bugzilla.mozilla.org/show_bug.cgi?id=1249971

[carragom]

I really appreciate your input but still you fail to address the proposal and keep focusing on Firefox. I don't think I'll ever be able to convince you that IMO Firefox is actually doing the right thing here, but let me try.

The way I see it, Firefox does work correctly from anywhere in your filesystem without been installed.

• Download the AppImage or the .tgz, place it anywhere and run it. No installation required. It just works.
• Move the AppImage or the tgz content to another location and run it again, it just works.
• Copy the AppImage or the tgz content to another location and run it again, it just works.

But there is more, Firefox will go the extra mile to realize that this is a different copy of the application and create a new profile for it so it does not clash with another copy. This way you are able to run multiple editions (esr, stable, dev, nightly) and multiple versions of each edition without them trampling on each other's profiles. Hell you could even run multiple copies of multiple edition/version combo. If this is not a portable application I don't know what to call it.

The way Firefox infers what profile to use for each copy is derived from the location of the binary. Personally I think this would be the obvious solution to this problem, I don't see any issues with it and I even fail to think of a better solution that does not depend on the binary location.

As a user, I don't want Firefox to change it's behavior because it's very convenient and offers a lot of flexibility especially for an application that can be run from anywhere in your filesystem.

I hope I was able to convey my appreciation on how Firefox works. And yes you might disagree and that is OK.

[TheAssassin]

In general, I think the idea is worth considering because it would solve one long-standing AppImage annoyance which is mounting an AppImage more than once. If done right, predictable mount points could really shine. I would, however, not try and encode a path into the mount point path, that is what hashes are good at.

The same can however also be achieved with a unique random ID (e.g., a UUID4) embedded in the AppImage header.

[probonopd]

long-standing AppImage annoyance which is mounting an AppImage more than once

If this is a "long-standing AppImage annoyance", I must say I never really ran into it or it simply never annoyed me.

Imagine you run multiple instances of an application from the same AppImage. How does that AppImage runtime know when it is time to unmount?

[carragom]

Imagine you run multiple instances of an application from the same AppImage. How does that AppImage runtime know when it is time to unmount?

@probonopd This is a very good point. Multiple instances and umounting issues. How about just try to unmount and ignore if mount point is busy because this means there is another instance running, this way only when the last instance closes unmount will succeed ? Would that make sense ?

[carragom]

In general, I think the idea is worth considering because it would solve one long-standing AppImage annoyance which is mounting an AppImage more than once. If done right, predictable mount points could really shine. I would, however, not try and encode a path into the mount point path, that is what hashes are good at.

The same can however also be achieved with a unique random ID (e.g., a UUID4) embedded in the AppImage header.

@TheAssassin I agree that the encoding I presented is not good at all. There are better options for example pipenv has predictable virtual environment paths based on the project's path e.g. a project in /home/cramos/src/my-project always gets virtual environment cramos-ZhOOI4Cc. We could check which encoding is used there. Another option could be citihash. Seems like there are good proven options for this.

[TheAssassin]

Well, I have seen the file descriptor limit being exhausted. Sure, it happens only rarely when using AppImages, e.g., in scripts that spawn a lot of processes.

[probonopd]

This very special case is imho best handled in a custom AppRun file that makes creative use of $APPDIR (which will point to the mountpoint at runtime) and ln -s...

[Samueru-sama]

Have you checked if this issue isn't fixed by setting MOZ_APP_LAUNCHER="${APPIMAGE}" in the AppRun?