You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The file .last_revision is stored under $SNAP_USER_DATA (revision specific), 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) 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.
The text was updated successfully, but these errors were encountered:
The file
.last_revision
is stored under$SNAP_USER_DATA
(revision specific), 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) 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:
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.The text was updated successfully, but these errors were encountered: