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.