GNOME Bugzilla – Bug 765723
g_desktop_app_info_new_from_filename returns NULL if the executable does not yet exist.
Last modified: 2018-05-24 18:52:45 UTC
g_desktop_app_info_new_from_filename returns NULL if the executable specified with the "Exec" entry does not yet exists. This used not to be the case in the past and it causes several regressions e.g. [1]. [1] https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1574759
The regression actually came because of recent changes to file monitors. This impacts code in gnome-menus which tries to load newly-created desktop files. When an app is installed by dpkg it might be the case that the desktop file is unpacked before the binary is unpacked, causing the desktop file to fail to load. With the old file monitors there was enough of a delay that this wasn't likely to happen (since the executable would likely be in place by the time the file monitor fired). Now, since we read the file immediately, the failure is much more likely to occur. I never liked the Exec= line check on account of its performance implications. This bug has finally pushed me to want to remove the check entirely.
Created attachment 326940 [details] [review] Revert "desktopappinfo: check whether the specified executable is valid" This reverts commit f641699299ed2713cf247e3465bb1a21612b36f7. This change was introduced as part of bug 675333, but in my opinion has been more trouble than it's worth. Let's remove it. If we still want to solve the problem in that bug, we should look at alternative approaches.
To play devil's advocate to myself, it's worth thinking about the fact that this could also impact the ability to properly load the icon of the app in question, for the same reason. To play devil's advocate to my devil's advocate, it's worth mentioning that at least in that case we've properly loaded the desktop file and we would be capable of installing a watch on the icon file (which we arguably may want to do anyway). I tried to blame this on dpkg, but Seb was having nothing of it... in a certain sense, this entire bug is clearly caused by our continued use of non-atomic installs/updates... but since that's our state of the art...
Created attachment 327011 [details] [review] mimeapps test: invert check for non-existing Exec= The 'mimeapps' testcase tested to make sure that GDesktopAppInfo would fail to instantiate a desktop file that had a missing binary (as specified in Exec=). We recently changed that behaviour, so test the opposite outcome now.
Review of attachment 326940 [details] [review]: I am OK with this as long as you verify that after the revert, the behavior for bug 675333 is still sane. In other words, it should be possible to forget associations for apps that don't have a valid Exec.
(In reply to Cosimo Cecchi from comment #5) > Review of attachment 326940 [details] [review] [review]: > > I am OK with this as long as you verify that after the revert, the behavior > for bug 675333 is still sane. > In other words, it should be possible to forget associations for apps that > don't have a valid Exec. That sounds like we should have a testcase for it.
The TryExec check is still there so new applications won't be added to the menu structure if their desktop files have TryExec and the desktop file is unpacked earlier than the referenced executable…
(For Unity and other environments using gnome-menus bug 764277 is probably relevant.)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1164.