go-appimage icon indicating copy to clipboard operation
go-appimage copied to clipboard

AppImageD: Randomly goes off on to my connected disks like my backup disks, indexes and links old versions in my backups to my app menu

Open abclution opened this issue 8 months ago • 10 comments

So randomly, usually a day or so after I reinstall (to get rid of all the extras) AppImaged scans random disks and slaps all the AppImages it finds into .desktop links in my menu.

Its terribly annoying when it does this and I want to know how to make it stop.

abclution avatar Apr 06 '25 10:04 abclution

The desired behavior is to add all AppImages to the menu, isn't it? So I would say "works as designed".

probonopd avatar Apr 06 '25 14:04 probonopd

no, these are OLD BACKUPS and old versions of appimages not meant to be used unless needed and will be restored to correct locations. ex. on backups and zfs snapshots.

i have newer versions in the correct areas. I really need to limit its search path. Having 4+ identical icons to different versions is not user friendly, its just confusing. and way more clicks to figure what and where each icon goes to than its worth

abclution avatar Apr 06 '25 16:04 abclution

So how, in your opinion, should appimaged handle applications stored on removable media?

We have a whole source code file dedicated to handle disks that come and go for this very purpose: https://github.com/probonopd/go-appimage/blob/master/src/appimaged/udisks.go

probonopd avatar Apr 06 '25 18:04 probonopd

Well, my backup disks are permanently mounted for the most part. But The real issue is having this daemon stomping around my disks and having no way to limit it to where I want it. Right? There is no way to tell it to stay only in path and the ~Applications which if I recall the documentation says it stay within. OH and desktop if i recall..

So it stomping around outside of its documented area is technically out of spec on its own design. So Im having to decide wether my menu is cluttered with old archived versions of appimages i keep for some time due to bad / incompatible updates, make my user not have access to read those files via security permissions (so the daemon also has no access) or?

If the daemon did what it was documented to do, it would be gucchi.

From the docs Folders being watched for AppImage files:

/usr/local/bin /opt ~/Applications ~/.local/bin ~/Downloads $PATH, which frequently includes /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, and other locations

It seems to be looking at every single accessible path. Thats not ok.

abclution avatar Apr 06 '25 21:04 abclution

It looks like it's missing from the README, but appimaged, in addition to the listed directories, it also looks for an Application folder at the root of mounted disks. It should only integrate at startup, otherwise it only integrates files or disks as they change. If it is seemingly happening randomly I suspect it's crashing and systemd automatically restarts it.

CalebQ42 avatar Apr 06 '25 23:04 CalebQ42

Yes but I dont have them there. Here is one AppImage it insists on indexing and it is significantly more buried than that.

Image

abclution avatar Apr 06 '25 23:04 abclution

Very weird. I'll double check some things, but there shouldn't be any reason they are being checked unless the directory is directly mounted or n PATH. We aren't interested in doing any directory traversal and it should only be checking the files directly in the watched directories.

CalebQ42 avatar Apr 07 '25 03:04 CalebQ42

Ya well thats what I was alluding to.. it pulling these from where they are at is not expected behavior methinks

My path sir

/bin
/fixd-toolkit/AppImages
/fixd-toolkit/AppImages/AI
/fixd-toolkit/AppImages/ANDROID
/fixd-toolkit/AppImages/#ARCHIVE
/fixd-toolkit/AppImages/Audio
/fixd-toolkit/AppImages/BARCODES
/fixd-toolkit/AppImages/CADDRAWING 
/fixd-toolkit/AppImages/CLOUD
/fixd-toolkit/AppImages/Creation
/fixd-toolkit/AppImages/Crypto
/fixd-toolkit/AppImages/Data
/fixd-toolkit/AppImages/Discord
/fixd-toolkit/AppImages/Editing_TEXT
/fixd-toolkit/AppImages/Entertainment
/fixd-toolkit/AppImages/FILE-MANAGEMENT
/fixd-toolkit/AppImages/GAMING
/fixd-toolkit/AppImages/ORGANIZATION-PAPERWORK-BOOKS
/fixd-toolkit/AppImages/PHOTO-IMAGE-MANAGEMENT
/fixd-toolkit/AppImages/PRIVACY
/fixd-toolkit/AppImages/REMOTE-ACCESS
/fixd-toolkit/AppImages/SCANNING
/fixd-toolkit/AppImages/Sentry
/fixd-toolkit/AppImages/StabilityMatrix
/fixd-toolkit/AppImages/StabilityMatrix_a16ee9e3f831c514f456e669c26f7518_e4414526d2c3ddd0fc191121349a1091.AppImage.home
/fixd-toolkit/AppImages/SubtitleEdit
/fixd-toolkit/AppImages/UTILITIES
/fixd-toolkit/AppImages/UTILITIES_AppImage
/fixd-toolkit/AppImages/UTILITIES_GPU
/fixd-toolkit/AppImages/VIDEOS_Editing
/fixd-toolkit/bin
/fixd-toolkit/sbin
/fixd-toolkit/scripts
/home/user/.local/bin
/home/user/.local/bin
/home/user/.local/kitty.app/bin
/home/user/.local/sbin
/home/user/miniconda3/condabin
/snap/bin
/usr/bin
/usr/games
/usr/local/bin
/usr/local/games

abclution avatar Apr 07 '25 10:04 abclution

I got around to checking things out and appimaged in fact does not do any directory traversal, it's only checking the files directly inside the watched folders. My best guess is that whatever you are using to do backups is mounting the directory, which is causing appimaged to detect the old AppImages.

You can see your current mountpoints with df --output=target. I suspect that while the old AppImages are showing up, your backup home folder is mounted.

CalebQ42 avatar Apr 10 '25 06:04 CalebQ42

I double checked in case there was overlay mounts happening, did not seem to be the case. Additionally i setup a bind mount dir for some NFS shenanigans and its now finding those also lmfao and the remote nfs mount.

Alright, I give up on it it makes no sense. I just wont run it constant. I literaly just want it to look on the ~/Applications/ recursively and thats it.

but it does whatever it wants.

Image

abclution avatar Apr 13 '25 02:04 abclution