Desktop extension doesn't update GDK pixbuf module cache when reverting

Bug #2041182 reported by Guillaume Beuzeboc
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Snapcraft
New
Undecided
Unassigned

Bug Description

The file .last_revision is stored under $SNAP_USER_DATA (revision specific)(https://github.com/snapcore/snapcraft/blob/main/extensions/desktop/common/init#L34), that is supposed to store the number of the revision.
Only if the content of the file changed (which normally cannot happen since only the dedicated revision can access its dedicated $SNAP_USER_DATA) or if the file didn't exist (first start) the snap is going to "update".
This update is especially generating the GDK pixbuf module file (the cache file, https://github.com/snapcore/snapcraft/blob/main/extensions/desktop/common/desktop-exports#L414) in the $SNAP_USER_COMMON (common to revisions). This cache file is holding hardcoded absolute path to libraries.

The scenario that is causing the problem:

- install rev 1
  - launching it
  - need update since no .last_revision file
  - generating the cache file pointing to rev 1 lib
  - writing the last_revision file
- install rev 2
  - launching it
  - need update since no last_revision file
  - generating the cache file pointing to rev 2 lib
  - writing the .last_revision file
- reverting to rev 1
  - launching it
  - .last_revision file already exist and contains the rev 1
  - no need to regenerate the cache
  - crash because we used the cache file pointing to rev2 libraries

Because the .last_revision file is stored in a revision specific space, it cannot contain anything else than the revision it's supposed to hold. Hence, it is only used at the first launch. No update can happen otherwise.

Having the cache stored in a revision common space and the file controlling its update in a revision specific space seems to be the issue.

If the .last_revision file was placed in the $SNAP_USER_COMMON space it would allow a snap to "update" (thus regenerate the GDK pixbuf module file) after a revert.

This issue seems to affect gnome extension for all core versions. Additionally, the electron-builder snap is also affected by it.

description: updated
Revision history for this message
Ken VanDine (ken-vandine) wrote :

I do think it would be safer to move .last_revision to $SNAP_USER_COMMON to ensure it doesn't follow the snap with the revert. In the process of making that change we should also delete $SNAP_USER_DATA/.last_revision if it exists.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.