https://bugs.freedesktop.org/show_bug.cgi?id=57061
Stephan Bergmann <sberg...@redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|sberg...@redhat.com |libreoffice-b...@lists.free | |desktop.org Summary|No personal data imported |Not all personal data |(or moved) during install |imported during install |from /3 User Profile |from /3 User Profile Version|4.0.0.0.alpha0+ Master |4.0.0.3 rc --- Comment #27 from Stephan Bergmann <sberg...@redhat.com> --- In reply to comment 24 and comment 26: In general, what parts of an old user profile are migrated is controlled by configuration settings in the /org.openoffice.Setup/Migration tree (see officecfg/registry/data/org/openoffice/Setup.xcu). The data that is present there is apparently mostly what had been there for the migration from OOo 2 to OOo 3 already. The reason why certain parts of a user profile had been excluded from migration back than are probably lost to history. Note that this user profile migration code already kicked in on Linux during the LO 3 timeframe, when <http://cgit.freedesktop.org/libreoffice/core/commit/?id=9276f7d5740a28b342db2a9bcd8644ff2f4f5742> "fdo#32263" moved the location of the user profile from ~/.libreoffice/3 to ~/.config/libreoffice/3 and <http://cgit.freedesktop.org/libreoffice/core/commit/?id=6b522673373797bbf53d795d53e0ec45175a5d67> "default config location has changed, look in old config dir when migrating" enabled LO's migration code to migrate from an existing ~/.libreoffice/3 to a new ~/.config/libreoffice/3. Therefore, at least my assumption would have been that that migration worked acceptably, or else (Linux) users would already have complained when upgrading from old LO 3 versions (that used ~/.libreoffice/3) to newer LO 3 versions (that used ~/.config/libreoffice/3) about settings getting lost. However, re-checking that now, things like the list of recently used documents indeed were not migrated back then, either. Apparently nobody looked at the migration machinery in detail, whether it works acceptably for migrating individual settings to a new LO 4 user profile. Addressing specific items from the above comments: * List of recently used documents: This apparently manifests itself in configuration items (in the user profile's user/registrymodifications.xcu) in the /org.openoffice.Office.Histories tree, which is not included in the migrated data. Whether there ever was or still is any good (technical) reason for that I do not know offhand. * Window sizes: These apparently manifest themselves in configuration items (in the user profile's user/registrymodifications.xcu) in the /org.openofice.Office.Views tree, which is not included in the migrated data. Again, wheter there ever was or still is any good (technical) reason for that I do not know offhand, but the odd format in which this data is saved makes it not unlikely that this was considered too fragile for migration at least in the past. * Autotexts: These apparently manifest themselves as files in the user/autotext/ directory, which explicitly are migrated (cf. ".*/autotext/.*" listed in /org.openoffice.Setup/Migration/SupportedVersions['OpenOffice.org3+OpenOffice.org2+StarOffice8+StarSuite8+Libreoffice3']/MigrationSteps['Common']/IncludedFiles in officecfg/registry/data/org/openoffice/Setup.xcu), and indeed an existing ~/.config/libreoffice/3/user/autotext/mytexts.bau is copied to ~/.config/libreoffice/4/user/autotext/mytexts.bau and works fine in LO 4 at least when I try that out with my local master build on Linux. So this needs further verification. * View - Toolbars - Drawing: This apparently manifests itself in configuration items (in the user profile's user/registrymodifications.xcu) in the /org.openoffice.Office.UI.WriterWindowState tree, which is not included in the migrated data. Again, wheter there ever was or still is any good (technical) reason for that I do not know offhand, but, again, the format in which this data is saved makes it not unlikely that this was considered too fragile for migration at least in the past. * context menu on toolbar Standard > Visible Buttons > New Document From Template: This apparently manifests itself in the file user/config/soffice.cfg/modules/swriter/toolbar/standardbar.xml. The migration data mentioned above lists ".*/config/soffice.cfg/modules/.*/toolbar/custom.*\.xml", but that apparently does not match this file, so it is not copied. What's the story there I do not know. * Tools > Customize... > Menus: This apparently manifests itself in the file user/config/soffice.cfg/modules/swriter/menubar/menubar.xml, which is not included in the migrated data. Again, what's the story there I do not know. * "Is it not the easiest way just to copy (or rename?) the /3 user profile to a new /4 profile, if LO does not find a /4 profile at start?" While most of the old data could indeed be reused, a new major release is generally considered a good point in time for incompatible changes in user profile data, thus demanding more sophisticated migration than wholesale copy/rename. There is at least some changes (like changing bundled extensions into core parts, and changing the database format for information about installed extensions) that benefited from this for LO 4. * "The files 'MIGRATED' or 'MIGRATED4' are just confusing. As I understood they are necessary for development." No, see <http://cgit.freedesktop.org/libreoffice/core/commit/?id=995a87e5cf63fe1626245b62fef4aa71fa02dc94> "disable multiple migrations via MIGRATED stamp file" for the reason the MIGRATED file got introduced. Having said that, I personally think that design is flawed, and we best get rid of those flag files again; I have that on my to-do list. * "Does someone know if there is a forward compatibility of LO 3.6.x to /4 user profiles if they are renamed to /3?" There is no guarantee for that to work. If it works, it works by chance, not by design. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs