LibreOffice_5.1.2_Linux_x86-64_rpm.tar.gz Dear Libre Office, User profiles corrupt a lot after upgraded. (It is really a common occurrence for me.) See bug 99490 for lost spell checker. Now the custom dictionary is easy to copy back from the old corrupted profile but the recents are not as it is included in registrymodifications.xcu. Request for Enhancement: Please break the recents into their own file so they can be easily restored after having to create a new profile. Many thanks, -T
Thanks Tod. The idea is logic. Not sure if in the end the price (engineering, performance, maintenance) is worth the gain, but others can decide that. Cor
Usually it's enough renaming/deleting the file "user/registrymodifications.xcu", it affects all the options in Menu/Tools/Options, and the files "user/basic/dialog.xlc" and "scrip.xlc" are overwritten, additionally custom colors in "user/config/standard.soc" are lost. Maybe this could help in your case.
Closing as WONTFIX since suggestion from m.a.riosv is a good workaround. Basically updates must not break old profiles. Please file a bug report if this happens again.
*** This bug has been marked as a duplicate of bug 57466 ***
(In reply to Todd from comment #0) > Request for Enhancement: Please break the recents into their own file so > they can be easily restored after having to create a new profile. (In reply to m.a.riosv from comment #2) > Usually it's enough renaming/deleting the file > "user/registrymodifications.xcu", it affects all the options in > .... > Maybe this could help in your case. deleteng registrymodifications.xcu also deletes the recent files, so I don't see how this can be a solution. (In reply to Heiko Tietze from comment #3) > Closing as WONTFIX since suggestion from m.a.riosv is a good workaround. nor a work around ;)
If you delete the profile, the MRU list and support for thumbnail views is purged. Moving the Histories stanzas from the registrymodifications.xcu to a HISTORIES directory would make it a bit easier to copy that directory prior to clearing profile, and then restore it reliably. To be honest when QA testing I am sometimes reluctant to clear my profile because I would prefer to keep my MRU list and the Thumbnail views. Placing the MRU and history into its own folder would encourage me to work with a clean profile more often knowing I could restore my MRU list without fuss.
I support the request to store the recent files list becide the registrymodifications.xcu. Storing the history, more exact the link and the thumbnail of each file in the registrymodifications.xcu, makes the file huge.
*** Bug 103445 has been marked as a duplicate of this bug. ***
*** Bug 90094 has been marked as a duplicate of this bug. ***
+1 from me, echoing Regina from comment 7. And additionally: (In reply to Todd from comment #0) > User profiles corrupt a lot after upgraded. (It is really a common > occurrence for me.) Yes, the profile corruption is really frequent. And the most actively written file in the profile is registrymodifications.xcu, which is likely the most frequently corrupted file. Now if we move thumbnails out from it, its typical size will shrink many times, and so it would possibly allow to decrease the likelihood of corruption of the file (questionable), which in turn could decrease the very problem that triggered this request.
(In reply to Mike Kaganski from comment #11) > Yes, the profile corruption is really frequent. And the most actively > written file in the profile is registrymodifications.xcu, which is likely > the most frequently corrupted file. Are there any examples of such corrupted registrymodifcations.xcu? What exactly does the corruption look like? If you look at how registrymodifications.xcu is written in writeModFile (configmgr/source/writemodfile.cxx), it is first created as a temp file (in the same directory as the target registrymodifications.xcu) and then copied (hopefully atomically) with TempFile::closeAndRename -> osl::File::replace. So it is probably unlikely that there are any "only written halfway" or similarly corrupted instances of that file.
*** Bug 152041 has been marked as a duplicate of this bug. ***
I support this enhancement request from a QA perspective: - Easier to spot where the issue comes from with smaller files: thumbnails take most of the file and make it more difficult to navigate it and find the human-readable bits - Easier to avoid sharing sensitive data: users might be reluctant to share files if they are an aggregate of many types of sensitive data (contact details, recent document thumbnails); or they might not even know they are sharing sensitive data, as many won't be aware images can be base64-encoded and contained in a text file.