albertlauncher
Albert seems to cache .desktop Exec properties
Albert seems to cache .desktop Exec properties
if the .desktop Exec properties are changed after albert is started - the albert does still execute the old cached .desktop Exec contents
This could very well be, I think albert holds an inotify watch on the directory to see additions/deletions but not the files themselves. But there is a scan interval, isn't there? This sound like a minor inconvinience when working on .desktop files but no day-to-day problem.
no matter what - I'd say that it is still a bug....
It has hit me several times - you update something with your package manager - and then launch that application/program...immediately after - using albert
If something has changed in the .desktop file you will execute the old contents of the desktop - not the new contents...
I am not sure if it is a good ides to setup (count of apps) file watches. They are a scarce and expensive resource
I am not sure if it is a good ides to setup (count of apps) file watches. They are a scarce and expensive resource
I agree - loading the Exec property on demand (execution) is the better chioise - then the problem is gone
I have also encountered this problem. I downloaded some software that was only available as an AppImage. In order to get launchers and menus to recognize it as an application I had to look up instructions on how to make a .desktop file to point to the AppImage file. The second time I did this I copied a pre-existing .desktop file for another application and just edited the contents. But Albert kept launching the previous application long after I had completely changed the contents of the new .desktop file.
To get Albert to stop launching the wrong application I ended up having to make a duplicate of the new .desktop file, delete the old one and then rename the copy back to the original name. That shouldn't have been necessary.
To get Albert to stop launching the wrong application I ended up having to make a duplicate of the new .desktop file, delete the old one and then rename the copy back to the original name. That shouldn't have been necessary.
I agree - I've never seen Albert beeing able to recover from this problem by itself
@RedBearAK sounds a bit overcomplicated. Why not just restart Albert?
Imho the gain (as Martin said just a minor inconvenience) justifies none of the possible solutions overhead (Filesystem Watchers for each file - expensive, uninformed regular scans - does not have information immediately, online exec key parsing - keywords still out of date @uffejakobsen, online desktop file parsing - keywords not available at all). If any automatic solution then I'd tend to file system watches.
The docs state though
The act of monitoring files and directories for modifications consumes system resources. This implies there is a limit to the number of files and directories your process can monitor simultaneously. On all BSD variants, for example, an open file descriptor is required for each monitored file. Some system limits the number of open file descriptors to 256 by default. This means that addPath() and addPaths() will fail if your process tries to add more than 256 files or directories to the file system monitor. Also note that your process may have other file descriptors open in addition to the ones for files being monitored, and these other open descriptors also count in the total. macOS uses a different backend and does not suffer from this issue.
Otherwise you can still restart Albert. Maybe some mdate tricks may help. Do you have any ideas for a proper solution? Otherwise I'll close this issue.
@ManuelSchneid3r
I believe that the whole reason I went to the extent of deleting and recreating the desktop file was because restarting Albert didn't actually seem to get Albert to update its (assumed) internal database of the Exec commands embedded in the desktop file. I would restart Albert and it would just keep launching the same old Exec command from before the file was changed. At least, that's the way I remember it.
I think the solution is not necessarily to monitor a bunch of individual files but just to notice if any (desktop) file in any of the scanned application folders has been "touched" since the last update of the internal Albert database of Exec commands.
Is there really no low-resource way to know if any file in a watched folder has been modified (since $TIMESTAMP), as opposed to being completely removed, renamed, or added to the watched folder? It's when desktop files are edited in place that this issue happens.
At the time of my reporting there was two issues that I was trying to report with this github issue.
- Albert did not seem to discover that a desktop file had changed:
it kept using a cached copy of the old (and now obsolete desktop file information
- not even a restart of albert helped. Now I have not looked at the code:
- rebuilding the whole cache for every restart would be a brute force solution - but it would work.
- a smarter solution would be recording of ctime and mtime along with the other cached desktop info.
Just as @RedBearAK I'm not in suggesting that setting up FS watching events for every cached desktop file - simple rescan and revalidation from timestamps should be sufficient.
- once a desktop file entry had been qualified in albert it would perform the execution based on the cached info - which may be wrong at the time of execution. Here it would be rather simple to check the recorded ctime and mtime against the actual file and detect that the cached file info is not the most recent
Which versions are you guys using? Actually there is no cache at all. indexing begins from scratch every time. at least not on hard disk. so state can not persist over albert restarts. but yes if a file changes (e.g. by vim) the extension probably does not notice it, but overwriting it (e.g. by an update) should definitively trigger a new scan. Are you using old versions?
Which versions are you guys using?
As I¨m maintaining the AUR pkbuild for albert-minimal - and hence I¨m following the releases closely I was using 0.17.3 - went to 0.17.5 about a week ago - but havenøt had the time to go to 0.17.6
You could trace stdout. There you will see when exactly the app ext does rescans.