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

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.

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?

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 ?

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.

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.