User installation migrated onto itself

[Stephan Bergmann]

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
>> <http://cgit.freedesktop.org/libreoffice/core/commit/?id=995a87e5cf63fe1626245b62fef4aa71fa02dc94>
>> "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 
again.)

>> 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 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=76e0d695a41326a5583dbc9702e0ce3b8219b514> 
"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.)

Stephan