1709969 - Migrate from an existing profile when running from an app package for the first time

Status: RESOLVED FIXED

(Firefox :: Installer, task)

Description

[Molly Howell (she/her) (no longer active)]

The path to the virtual file system for an app package includes the package's version number, which means our installation path is not stable between app updates. Therefore, if install-specific profiles are used, a new profile will be created and the previous one lost on each update. There are few ways around this, but the simplest is to just not use install-specific profiles.

This is handled here for Snap packages.

However, one potential complication in doing this comes from how file system virtualization works. In recent Windows 10 builds, writes to files that already exist in the "real" AppData are actually made to those files, not to virtual copies. But new files are still created in the virtual file system. This could cause trouble if we accidentally open a preexisting profile, because then we would be writing different pieces of the same profile in both the virtual and "real" file systems, meaning the profile would be in an inconsistent state except from the perspective of the package.

So, the most reliable option might be to not use a regular default profile, and instead create a special, package-only one with a name that we know will not already exist, so that the entire profile is always contained inside the VFS. We may also want to block opening any profiles that aren't the designated package one(s), to prevent breaking them.

Comment 1

[Molly Howell (she/her) (no longer active)]

Attachment: Bug 1709969 Part 3 - Migrate from an existing profile when creating the dedicated profile for a Windows app package. r=agashlin!,mossop!

Comment 2

[Molly Howell (she/her) (no longer active)]

Attachment: Bug 1709969 Part 1 - Add a utility function to retrieve the current package's family name. r=agashlin

Comment 3

[Molly Howell (she/her) (no longer active)]

Attachment: Bug 1709969 Part 2 - Use the package family name to compute path hashes when in a package. r=agashlin

Depends on D120529

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6a80559a4055
Part 1 - Add a utility function to retrieve the current package's family name. r=agashlin
https://hg.mozilla.org/integration/autoland/rev/a6b917838765
Part 2 - Use the package family name to compute path hashes when in a package. r=agashlin
https://hg.mozilla.org/integration/autoland/rev/17ed7ca86998
Part 3 - Migrate from an existing profile when creating the dedicated profile for a Windows app package. r=mossop,agashlin

Comment 5

[Sandor Molnar[:smolnar]]

Backed out for causing xpc failures in test_select_profile_package

Backout link: https://hg.mozilla.org/integration/autoland/rev/3ce5a6590f0fb547157b73222e1f6084ffab1be1

Push with failures

Failure log

Comment 6

[Molly Howell (she/her) (no longer active)]

Okay, how about we just skip the new tests on not-Windows, since this whole feature doesn't run anywhere else.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9712279be87a
Part 1 - Add a utility function to retrieve the current package's family name. r=agashlin
https://hg.mozilla.org/integration/autoland/rev/5c95bc1d7a10
Part 2 - Use the package family name to compute path hashes when in a package. r=agashlin
https://hg.mozilla.org/integration/autoland/rev/5136d2f68401
Part 3 - Migrate from an existing profile when creating the dedicated profile for a Windows app package. r=mossop,agashlin

Comment 8

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/9712279be87a
https://hg.mozilla.org/mozilla-central/rev/5c95bc1d7a10
https://hg.mozilla.org/mozilla-central/rev/5136d2f68401