Today I deleted chromium with the command ‘snap remove chromium’. I then realized that not only the snap was deleted but also all data (saved passwords, bookmarks, etc).
Actually nothing bad happened as it was only on a testing machine but is this really a wanted behavior??
Not only were my chromium data deleted but all chromium data from all users(!) on the system.
I can imagine even worse scenarios.
To remove a mail app would delete all mails
To remove a bitcoin wallet would delete all the money
….
I think the way apt handles this is way better. It strictly separates the program and the configuration. Is there any way to also get this behavior with snaps?
Extra question: What would happen if one user has an encrypted home directory? Would this prevent him from data loss if another user deletes a snap?
I think that is the expected behavior when one wants to delete an application. Everything related with it should be deleted. Thus, Chrome’s saved password, bookmarks, cookies, application preferences and such should be deleted as well.
It annoys me when I delete an application and have to look for those folders/files. Thank god this is not Windows and loads of directories are left somewhere in your computer and will never get deleted unless you do it manually.
Regarding apt handling this better, I believe apt’s remove --purge does precisely the same. I may be wrong on this part though.
It’s great because you both, @heipa and @gsilvapt, presented exactly the two sides of that coin. That makes it easier to explain the solution we are working on right now, which should solve both ends of this problem in a nice way. We don’t want to either keep data lying around forever wasting space for no reason, and we don’t want people to kill their precious data without realizing either.
So here is the idea: we are working on snapshots right now. We’ll have commands to save all data for one or more snaps, restore it, discard it, and so on. Once that’s working, we’ll change the behavior of removals so that an automatic snapshot is performed at that time, with an important detail: it will have an expiration date set on it. If the snap is not reinstalled and the snapshot is not manually changed to a persistent snapshot, it will be eventually removed from the system automatically. The thinking is that if the administrator removes something and doesn’t come back for its data after a good while, the data is irrelevant and should indeed be discarded so it’s not wasting space.
So this solves both ends: we don’t just kill data on a mistake, and we don’t waste space arbitrarily either.
This save feature is preventing packages from being removed. $ sudo snap remove mysnap Save data of snap "mysnap" in automatic snapshot set #8 (cannot create archive: tar: 43/.history: Cannot open: Permission denied (and 1 more))
I don’t need to save anything and I don’t see anything like --no-save in manual.
Am I missing something?
Ah, sorry. That option arrived in snapd 2.40. If you would like it now, you can snap install snapd --candidate or wait a while for the stable release. (I’m running 2.40 here).
I ran the command you provided, snapd is now in snap list but it didn’t change anything.
$ snap --version
snap 2.39.2-1.fc29
snapd 2.39.2-1.fc29
series 16
fedora 29
kernel 5.1.20-200.fc29.x86_64
It would still be nice to figure out original error root cause and find a workaround.
The error message suggests a permission problem on ~/snap/mysnap/current/.history - perhaps check the permissions on that file. Are other files there similar? Can you change them, or remove the file if it’s not required?
$ find snap -name .history -ls
241634154 4 -rw------- 1 root root 118 Aug 12 07:42 snap/mysnap/43/.history
$
but I managed to unmount loop device manually, how do I mount it back? snap list shows disabled,broken in status column.
