[AppImage] When exiting the application links in ~/.local/bin are removed even when managed by another app

[mattfarina]

For bugs, describe what you're seeing
Let's say I have a symlink to helm in ~/.local/bin that isn't managed by RD via the AppImage. When I exit Rancher Desktop, this symlink is deleted along with kubectl, helm, kim, and nerdctl. It shouldn't be.

Note, we aren't currently shipping an AppImage. This is experimental.

To Reproduce
Steps to reproduce the behaviour:

1. Get or build an AppImage for Rancher Desktop
2. For one of the tools that we include linking support for (i.e., kubectl, helm, kim, nerdctl) create a link to something not related to Rancher Desktop.
3. Start and then exit RD.
4. See that the symlink is gone.

Expected behaviour
Symlinks should only be deleted if RD created it.

Setup (please complete the following information):

• OS: Linux
• Rancher Desktop version: main
• Kubernetes version: N/A

[davidcassany]

This is done intentionally, is not a bug. I agree this is not the best solution ever, but since AppImage is experimental I did not want to code new integration tools tracking logic only because of AppImage. See the logic for this behavior is here:

rancher-desktop/background.ts

Lines 216 to 226 in 3d260c4

	if (process.env['APPIMAGE']) {
	// For AppImage these links are only valid for this specific runtime,
	// clear broken links before leaving
	await Promise.all([
	linkResource('helm', false),
	linkResource('kim', false), // TODO: Remove when we stop shipping kim
	linkResource('kubectl', false),
	linkResource('nerdctl', false),
	]);
	}
	Electron.app.quit();

AppImage format, in short, is not more than an executable file that mounts an embedded squashfs image (that contains the app) to a temporary location on runtime. The mount location is a random temporary directory under ${TMPDIR}. The mount does not require privileges as it relies on FUSE, hence the host requires to have FUSE enabled (which the case in any relatively modern Linux desktop). You can see what AppImage is actually doing by calling:

$ DEBUG=1 my-app.AppImage --appimage-mount

The case is that at runtime the contents of the AppImage are available in a path that changes on every single run, hence if we keep the integration symlinks available RD on the next run it will complain that there is already some previous content that is not managed by RD. RD will not identify the present symlinks as they point to a non existing path and leave them there.

[adamkpickering]

I've noticed a related problem with the AppImage. On the first run after a factory reset, all of the binaries (helm, kubectl etc) will be there. But after exiting RD and starting it up again, they are gone. This is solvable by going into the Supporting Utilities tab and checking the boxes of the binaries you want to be present, but the user should not have to worry about this.

[adamkpickering]

Also, a related problem: the code David refers to above predates the docker integration, so there is no line to remove the docker symlink upon exit. Thus, it is left dangling.