Cron job to clean up old and/or broken desktop files

[TheAssassin]

Related to #18.

In #18, it is suggested to add TryExec keys to integrated desktop files to have launchers hide them if the files are not in place, to prevent users from using launchers that won't work.

However, this might lead to "broken" desktop files in the user's $XDG_DATA_HOME/application directory, which are, unlike with appimaged, never cleaned up. Therefore, we should add a cron job to the packages built by this project that takes care of cleaning up such files in the users' home directories.

Questions:

• Can the cron job be user-specific? If it can't, we will have to set up a system wide cron job that then needs to be written with extra care so that it won't delete files it shouldn't with root permissions.
• How often shall the cron job be run?
  • Running it too often might slow down the system. See [appimaged] Needs too much CPU, slows down Ubuntu 18.04 boot AppImage/AppImageKit#744 etc.
  • I think a daily cleanup should suffice. Desktop files are tiny, and shouldn't bloat the home directory horribly.

[TheAssassin]

User specific cron jobs are not an option, unfortunately.

Therefore, we have two alternatives:

One is to clean up the files while AppImageLauncher is being called. This could be done every time, or once a day (in this case, we just put an empty file somewhere, check its last access date and touch it after cleaning up).

The other one is a cron job running as root that sudo -sHu <uid>s and cleans up the files. This approach has two advantages: the functionality doesn't need to be written and maintained in C++, but can be written as a simple shell script. Furthermore, outsourcing this into a separate process that is running independently from AppImageLauncher means that the cleanup doesn't block an application start-up.

We could also combine both approaches, and fork off a shell script process that cleans up in the background (i.e., detached), while proceeding with launching the AppImage. However, the lack of control of the process makes this method a little more prone to errors.

[TheAssassin]

After some experiments, I decided to use the first approach, and run it on every launch for now. In native code, reading some desktop files (with a known vendor prefix), reading Exec/TryExec entries, and checking whether files exist is a pretty fast task.