User installation migrated onto itself
sbergman at redhat.com
Thu Mar 1 13:46:37 PST 2012
On 02/27/2012 02:36 PM, Michael Meeks wrote:
> On Mon, 2012-02-27 at 12:52 +0100, Stephan Bergmann wrote:
>> The migration happens only on the first start of LO 3.5, due to
>> "disable multiple migrations via MIGRATED stamp file." I do not
>> understand what propblem exactly that is supposed to solve.
> That file was asked for by Mechtilde. IIRC she was very concerned that
> without tons of testing of the migration paths we can easily get into
> situations where migration crashes as it starts, or produces a
> non-working install; and then users have to be instructed to remove not
> only their new user directory, but every old one too.
> So - this turns the flow into "it broke, fair enough, so just remove
> your settings directory and re-run and all will be well" - instead of
> some traumatised finding of versioned settings directories. I am
> assuming here that we don't need to do migrations inside a major
> version, ie. the version is encoded in the path.
OK, I understand that now. Makes sense. (Except, in those cases where
migration did not work as expected, you need to tell people now to
remove both their new user installation and the MIGRATED marker from the
old one when you given them a bug-fixed LO where migration works fine
>> And would it not be better anyway to only migrate an old user
>> installation if the new user installation does not yet exist ?
I meant something like
"Move migrateSettingsIfNecessary into create_user_install," which
appears to work fine and should avoid the Mac/Windows problem of
migrating a user installation onto itself. (And should also shave off a
slight amount of disk access from each start up.)
More information about the LibreOffice