App unable to write to ~/snap/<app>/<version> after background refresh

[tomjwatson]

I can consistently reproduce this with an app I am developing.

If the snap refreshes to a new version in the background whilst the app is open, the app suddenly can no longer write to ~/snap/<app>/<version>/.

e.g. I get errors like:

EACCES: permission denied, open '/home/<user>/snap/<app>/64/.config/<version>/logs/main.log'

Restarting the application, which switches the version in current over to the latest version, fixes the problem. Inspecting the filesystem whilst this is happening doesn’t show any difference in permissions or ownership between ~/snap/<app>/<old version>/ and ~/snap/<app>/<new version>/.

Any idea why this could be happening? I can’t find any relevant threads - is this a known issue?

Thanks!

[ogra]

you should use either the env variables “$SNAP_USER_DATA” and “$SNAP_USER_COMMON” to point to the dirs or specify it like:

/home/$USER/snap/$SNAP_NAME/current/ in whatever config you use in your app … the “current” symlink is updated dynamically and transparently … if you run any daemons they need to be restarted from an upgrade hook …

along with this there is:

[WIP] Refresh App Awareness

This thread summaries an upcoming feature of snapd that is something many application developers were asking for a long while now. Internally we call it refresh-app-awareness because it means snapd is aware of running applications and will inhibit refreshes of snaps with apps running. The feature is smart enough to filter out services that are restarted during refresh. Current Status The feature is currently under development, coming to snapd 2.39 behind a feature flag, that is, it will require…

[tomjwatson]

I’m actually not setting anything explicitly, I’m just relying on electron’s userData path.

I’ve actually found an issue on Electron detailing what’s going wrong and why, along with a workaround that I will be testing out: https://github.com/electron/electron/issues/23854.