Chromium: is it really ok to copy the data in each revision?

The snap app HOME is the /home/USER/snap/chromium/494, some applications like Chromium will store data in this directory, the directory may have many files and will be very large.

As far as I know, when refresh a revision, the content in the home directory will be copied to new home directory, such as copy from /home/USER/snap/chromium/494 to /home/USER/snap/chromium/495, this cause some issues:

  1. The directory is very large, copy will waste disk space
  2. After using new revision for a week, I find a critical bug, then I need to revert to old revision, then the one week data will loss.
  3. How can the copy process safe while opening/using the home directory files.

I know the design purpose of snap app is very smart, all snap apps can upgrade and rollback safely, but the real world is complicated, do you have some ideas to overcome these issues?

In my opinion, the data backward compatibility should be handled by the application itself, not snap.

cc @oSoMoN

Applications can choose to store data in the common directory, and that is not copied around. In particular chromium does this for its cache, but not its config. That makes sense, to me.

For the versioned data we will be moving to doing snapshots instead of copying the data, once snapshots have been out there for a bit.

1 Like

Upstream chromium occasionally introduces backward-incompatible changes in the format used to store the profile data, when upgrading to a new major version of the browser. In such an event, rolling back to an older version of the application with an unmodified profile would render it unusable. This is the reason why the profile is stored under $SNAP_USER_DATA and not $SNAP_USER_COMMON.

@oSoMoN @chipaca

The directory size will be very large, in my case it is more than 2GB, copy these 2GB files in each revision will waste disk spaces.

Think about this case: After I upgrade chromium to a new revision, I install a chrome extension, after a while I found there is a critical issue in chromium that I need revert it, then I can’t find the chrome extension and I lost the data such as browser history, bookmarks, autofill(if I don’t use chrome sync).

And for backward compatibility issue, it is better leaving it to chromium, since for deb installation, users still have the case to rollback chromium and encounter backward-incompatibility issue.

These issues are not chromium only, all snaps have same situation.

The only use case for snap to copy the home directory in each revision is that: after I upgrade to a new revision I found a critical issue immediately, then I can rollback and get the application work. BUt in real world, the critical issue may be found after sometime to use the application.

I am very like the snap packaging mechanism, but the copy data in each revision is a pain unless all snap apps take care of the app data and app configuration.

In my opinion, the application backward compatibility issues should be handled by application itself, not snap.

If an application has backward compatibility, it can provide a tool or some manual step to migrate the data to old or new format. Snap should just takes care of the packaging issue, not the user data.

By the way, is there an option to set the snap’s $HOME and $SNAP_USER_DATA to the user’a actual HOME(/home/username) directory?

Backward compatibility is a russian roulette, you can’t simply assume it exist and is supported.

I don’t think Chrome/chromium supports backwards compatibility as rollbacks aren’t chromium feature but snap. In firefox there was explicit note that downgrading from FF 56 will break profiles.

Snap supports rollbacks but tries to be fail-safe at the cost of some additional storage. Imagine what you would do when rollback to previous revision will irreversibly damage your profile and all you history, bookmarks and so on will be lost.

Thank you for your reply.

I switched to flatpak which does not care the config data of the app when updating the app.

I still think the config data should be cared by the app user and app developer, not by Snap/Flatpak platform.

The use case is:

  1. I installed a snap app, version 1

  2. I configured the snap app with key1=val1

  3. I upgraded the snap app, version 2

  4. I configured the snap app with key1=val1, key2=val2

  5. After sometime, I found version 2 has some issues, then I reverted it to version 1

  6. AHA, I lost my config key2=val2

That’s fine but there is no chromium flatpak actually :slight_smile:

I understand your usecase but can you answer below question?