Bug 37195 - Dictionary access lost after LibO upgrade
Summary: Dictionary access lost after LibO upgrade
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
3.4.0 Beta5
Hardware: All All
: high critical
Assignee: Caolán McNamara
URL:
Whiteboard:
Keywords: regression
: 37439 38500 39090 39731 39840 40065 40360 40493 40691 41241 (view as bug list)
Depends on:
Blocks: mab3.4
  Show dependency treegraph
 
Reported: 2011-05-14 04:07 UTC by wope
Modified: 2018-02-26 11:19 UTC (History)
19 users (show)

See Also:
Crash report or crash signature:


Attachments
my language settings (74.41 KB, application/vnd.oasis.opendocument.graphics)
2011-05-14 05:20 UTC, wope
Details
Broken spell check – screenshot 'missing_dicts_libo340b5.png' (17.54 KB, image/png)
2011-05-14 07:59 UTC, manj_k
Details
Screenshot: User profile Beta 4 - broken (58.88 KB, image/png)
2011-05-14 09:46 UTC, manj_k
Details
Screenshot: User profile Beta 3 - OK (62.57 KB, image/png)
2011-05-14 09:48 UTC, manj_k
Details
Screenshot 1: No available language modules (32.25 KB, image/png)
2011-06-20 15:20 UTC, manj_k
Details
Screenshot 2: All bundled dictionaries are available. (40.72 KB, image/png)
2011-06-20 15:21 UTC, manj_k
Details
Renamed folder 'bundled_old_7' (19.64 KB, application/zip)
2011-06-20 15:23 UTC, manj_k
Details
New folder 'bundled' (18.85 KB, application/zip)
2011-06-20 15:24 UTC, manj_k
Details
Comparison: registrymodifications.xcu_1–3.xcu [zip archive] (deleted)
2011-06-21 14:32 UTC, manj_k
Details
obsolete file 'configmgr.ini' (user profile) (3.82 KB, text/plain)
2011-06-22 12:12 UTC, manj_k
Details
current file 'configmgr.ini' (program folder) (3.82 KB, text/plain)
2011-06-22 12:14 UTC, manj_k
Details
CMD script that fixes the issue. (479 bytes, text/plain)
2011-09-02 01:17 UTC, rpr
Details
Fix to be execute in user-space (Windows only) (636 bytes, text/plain)
2011-10-10 09:36 UTC, Rainer Meier
Details

Note You need to log in before you can comment on or make changes to this bug.
Description wope 2011-05-14 04:07:40 UTC
1. deinstall older versions
2. install LibO 3.4.0 Beta5
-> no spelling available
3. delete the user-directory
4. start LibO 2 times
-> all is ok
Comment 1 Rainer Bielefeld Retired 2011-05-14 04:37:20 UTC
NOT reproducible] with "LibreOffice 3.4Beta5  – WIN7  Home Premium  (64bit)
German UI [DEV300m103 (Build:5)]" installed to 
"C:\Program Files (x86)\LibreOffice 3.4" using my existing user Profile.

Might be installation or lingucomponent issue or simply something with reporter's PC

@wope:
Please mention my hints in Bug 37196 - LOCALHELP not available and contribute more information:
- What were your former versions
- What languages
- anything unexpected visible (no dictionary languages checked ...
- anything else that might be related
Comment 2 wope 2011-05-14 05:20:28 UTC
Created attachment 46705 [details]
my language settings
Comment 3 wope 2011-05-14 05:24:57 UTC
- the OS is Win 7 professional (64bit)
- i made a standard installation
- the language is Deutsch (Österreich) 
- during the installation, all seems ok
- it happens another men (vohe) see the thread in http://listarchives.libreoffice.org/de/discuss/msg05244.html
Comment 4 manj_k 2011-05-14 07:57:22 UTC
I cannot reproduce the bug with a clean installation and default user profile (on WinXP).

So it seems that it is not an 'Installation' bug, but rather (maybe) 'Linguistic component'. 

However, I have remarked a similar issue with LibO 3.4 Beta 5 the first time today: 
After having removed the program folder of Beta 5 (first installation four days ago), and then installed Beta 5 again yesterday (also w/o system integration, setup /a), keeping the same user profile.

(The user profile of the first installation has been modified in the meantime due to usual work, a lot of testing, changed options, added/removed extensions etc.)

Today--I still don't know the cause--spell check was broken and 'Tools > Options > Language Settings > Writing Aids > Available language modules > Edit...' showed only 'German (Austria)' und 'Swahili (Tanzania)' (see attached screenshot 'missing_dicts_libo340b5.png').

I could clear spell check with the steps as follows:
1. Removing all added user extensions via Extension Manager
2. Removing following folders in the user profile '...\3\user\...':
- 'cache' in folder 'uno_packages'
- 'bundled', 'shared' and 'tmp' in folder 'extensions'

Spell check in all languages works fine again.
I couldn't reproduce the issue until now.
Comment 5 manj_k 2011-05-14 07:59:09 UTC
Created attachment 46712 [details]
Broken spell check – screenshot 'missing_dicts_libo340b5.png'
Comment 6 manj_k 2011-05-14 09:45:21 UTC
In addition I observed the following:

1. Running LibO 3.4 Beta 5 with the user profile of Beta 4:
Only the dictionaries for 'French (France)' and 'Spanish (Spain)'
are available.
(see attached screenshot: User profile Beta 4 - broken
missing_dicts_user_profile_340b4_1.png)

2. Running LibO 3.4 Beta 5 with the user profile of Beta 3:
All installed dictionaries are available.
(see attached screenshot: User profile Beta 3 - OK
no_missing_dicts_user_profile_340b3_1.png

Spell check with both user profiles works well in their original program
(LibO 3.4 Beta 4 or LibO 3.4 Beta 3).
Comment 7 manj_k 2011-05-14 09:46:35 UTC
Created attachment 46720 [details]
Screenshot: User profile Beta 4 - broken
Comment 8 manj_k 2011-05-14 09:48:50 UTC
Created attachment 46721 [details]
Screenshot: User profile Beta 3 - OK
Comment 9 manj_k 2011-05-14 11:40:25 UTC
(In reply to comment #6)
> [...]
> 1. Running LibO 3.4 Beta 5 with the user profile of Beta 4:
> Only the dictionaries for 'French (France)' and 'Spanish (Spain)'
> are available.
> (see attached screenshot: User profile Beta 4 - broken
> missing_dicts_user_profile_340b4_1.png) [...]

That issue with spell check could be solved by removing the folders 'bundled', 'shared' and 'tmp' in the directory '...\user\3\extensions'.
Comment 10 Rainer Bielefeld Retired 2011-05-21 22:54:48 UTC
*** Bug 37439 has been marked as a duplicate of this bug. ***
Comment 11 Rainer Bielefeld Retired 2011-05-21 23:07:45 UTC
It seems that the problem only appears after an upgrade, not with a completely new installation with newly created user profile.

@Andreas
I saw you active in similar bug reports.
Please feel free to reassign if it's not your area!
Comment 12 Andras Timar 2011-05-26 05:00:44 UTC
I tried to reproduce it but I could not. So I put this bug back to the pool. Maybe someone else has more luck with it.
Comment 13 Rainer Bielefeld Retired 2011-06-20 07:45:43 UTC
Still a problem with "LibreOffice 3.4.1RC1  – WIN7  Home Premium  (64bit) German UI [OOO340m1 (Build:101)]"  after upgrade from 3.4.0 release. Worked fine after an upgrade from 3.3.3
Comment 14 vitriol 2011-06-20 08:44:40 UTC
*** Bug 38500 has been marked as a duplicate of this bug. ***
Comment 15 manj_k 2011-06-20 15:17:52 UTC
New sample (on WinXP 32b) with
(1) libreoffice-3-4~2011-06-17_07.51.49_LibO_3.4.1rc1_Win_x86_install_en-US_de_fr.exe
and
(2) libreoffice-3-4~2011-06-20_07.21.58_LibO_3.4.1rc1_Win_x86_install_en-US_de_fr.exe 
and 
a slightly customized user profile (added some extensions, changed some options)

(Installation as server image - setup /a)

1. Do some spell check with the older version (1). ;)
2. Uninstall/remove LibO version (1).
3. Install the new LibO version (2) and keep the same user profile (bootstrap.ini).
4. Go to
'Tools > Options > Language Settings > Writing Aids > Available language modules > Edit...'
Unexpected: No available language modules. [Screenshot 1]

How to get access to the bundled dictionary extensions (language modules):
5. Close LibO.
6. Go to your user profile: rename the folder 'bundled'
[path: '...\3\user\extensions\bundled'], e.g.: 'bundled_old'.
7. Restart LibO:
A new folder 'bundled' will be created in the user profile.
All bundled dictionaries will be available. [Screenshot 2]

It seems that something is broken with registering or synchronizing the bundled dictionary extensions.
(Added for comparison:
- renamed folder 'bundled_old_7'
- new folder 'bundled')
Comment 16 manj_k 2011-06-20 15:20:45 UTC
Created attachment 48214 [details]
Screenshot 1: No available language modules
Comment 17 manj_k 2011-06-20 15:21:59 UTC
Created attachment 48215 [details]
Screenshot 2: All bundled dictionaries are available.
Comment 18 manj_k 2011-06-20 15:23:30 UTC
Created attachment 48216 [details]
Renamed folder 'bundled_old_7'
Comment 19 manj_k 2011-06-20 15:24:29 UTC
Created attachment 48217 [details]
New folder 'bundled'
Comment 20 Rainer Bielefeld Retired 2011-06-20 21:47:23 UTC
It's unacceptable that an upgrade destroys the existing configuration.
Comment 21 manj_k 2011-06-21 14:23:02 UTC
Another sample (on WinXP 32b) with
(1)
libreoffice-3-4~2011-06-20_07.21.58_LibO_3.4.1rc1_Win_x86_install_en-US_de_fr.exe
and
(2)
libreoffice-3-4~2011-06-21_07.44.29_LibO_3.4.1rc1_Win_x86_install_en-US_de_fr.exe

Installed (1) as server image - setup /a.
New default user profile created with (1)
Modified (Tools > Options):
- User Data: Name added
- jre 1.6.0_26 enabled
- Writer: Basic Fonts (Western) changed to DejaVu Sans
- no extensions added

Opened and closed a test file with several languages for spell check.

Test 1:
Installed (2) over (1).
All language modules available (as before). The bug doesn't occur.

Test 2:
Removed (2)
Installed (1) again
Same user profile (edited bootstrap.ini)

Unexpected:
'Tools > Options > Language Settings > Writing Aids > Available language
modules > Edit...' -
no language modules available (empty box)

Comparison 'registrymodifications.xcu':

1. 'registrymodifications.xcu_1'
after 'Test 1' (all right)
68 KB
Detail:
<item oor:path="/org.openoffice.Office.Linguistic/ServiceManager/LastFoundSpellCheckers">
- <prop oor:name="en-US" oor:op="fuse" oor:type="oor:string-list">
- <value>
  <it>org.openoffice.lingu.MySpellSpellChecker</it> 
  </value>
  </prop>

2. 'registrymodifications.xcu_2'
after 'Test 2' (broken)
58 KB
Detail:
<item oor:path="/org.openoffice.Office.Linguistic/ServiceManager/LastFoundSpellCheckers">
  <prop oor:name="en-US" oor:op="remove" /> 
  </item>

3. 'registrymodifications.xcu_3'
after 'Test 2' (opened and closed another test document)
49 KB
This item '...LastFound...' doesn't occur anymore.
Comment 22 manj_k 2011-06-21 14:32:17 UTC
Created attachment 48257 [details]
Comparison: registrymodifications.xcu_1–3.xcu [zip archive]
Comment 23 Rainer Bielefeld Retired 2011-06-21 22:34:07 UTC
Related Bugs?
Bug 38546 - No available language modules , spell check is impossible
Bug 36285 - LibO 3.4 beta1 – No available language modules, spell check is impossible

@Andras Timar:
May be you will see something upgrading from 3.4.1RC1 to 3.4.1RC2?
Comment 24 manj_k 2011-06-22 12:08:59 UTC
I think, the problem is the file 'configmgr.ini' in the user profile.
[Path: '...\<LibO-test>\3\user\extensions\bundled\registry\com.sun.star.comp.deployment.configuration.PackageRegistryBackend']

If you uninstall/remove the older version before installing the new version:

1. The bundled dictionary extensions will get new folder names '<abcdefg>.tmp' in the directory '...\Program Files\<LibO_34x_test>\share\prereg\bundled\registry\com.sun.star.comp.deployment.configuration.PackageRegistryBackend'

2. These folder names are components of 'configmgr.ini' (same path as 1.).

3. The user profile has also a file 'configmgr.ini' (path see above).

4. 'configmgr.ini' in the user profile has still the obsolete folder names '<hijklmn>.tmp' of the older version, and the file isn't updated by starting the new version of the program.

Copy 'configmgr.ini' from the program directory (2.), and paste the file to the user profile directory (3.) is my current workaround to get all available language modules (and bundled dictionaries).

So the bug seems to be that 'configmgr.ini' in the user profile isn't updated.

Added for comparison:
'user_configmgr.ini'
'program_configmgr.ini'
Comment 25 manj_k 2011-06-22 12:12:09 UTC
Created attachment 48301 [details]
obsolete file 'configmgr.ini' (user profile)
Comment 26 manj_k 2011-06-22 12:14:37 UTC
Created attachment 48302 [details]
current file 'configmgr.ini' (program folder)
Comment 27 Rainer Bielefeld Retired 2011-06-22 21:38:31 UTC
@manj_k: 
I see you really discovered important details. It would be great if you could try to find out wehter "Bug 38546 - No available language modules, spell check is impossible" (Linux) might be related.
Comment 28 manj_k 2011-06-24 06:59:09 UTC
Finally replicated with 'LibO 3.4.1 RC1' and 'LibO 3.4.1 RC2' (on WinXP 32b)
(see also Comment #21 and Comment #24)

Test 1
- Installed RC2 over RC1 ('bootstrap.ini' with the same user profile)
- 'configmgr.ini' (user profile) has been updated to the modified 'configmgr.ini' (program)
- All language modules are available (as before). The bug doesn't occur.

Test 2
- Removed/uninstalled RC1, then installed RC2 ('bootstrap.ini' with the same user profile)
- 'configmgr.ini' (user profile) has not been updated to the modified 'configmgr.ini' (program); due to the older 'xyz.tmp' names all 'dictionaries.xcu' files are lost for 'registrymodifications.xcu'.
- No language modules available (empty box).

Workaround: replacing the obsolete 'configmgr.ini' (user profile) with the new 'configmgr.ini' (from program)
Comment 29 westley52 2011-07-03 06:03:39 UTC
I found this bug report which I also found the work around independently.  manj_k  is absolutely correct - the 'configmgr.ini' is not being properly updated.  

I personally feel that this bug should deserve a MUCH higher importance level.  99% of the general folks using Libreoffice will not know how to update this file nor bother to research this problem, and an upgraded word processor without a working spellchecker is virtually worthless.  It would be great if someone could look at this. I have verified that this is still an issue with 3.4.1 final under Windows XP.
Comment 30 Rainer Bielefeld Retired 2011-07-04 05:56:30 UTC
After having done workarounds as per comments my "LibreOffice 3.4.1RC1 - WIN7  Home Premium (64bit) German UI [OOO340m1 (Build:103)]" now has a spellcheck, but it's impossible to add words to dictionaries during spellcheck, instead of showing dictionaries click on button is without any reaction.

On an other PC with same OS and LibO version, but with different upgrade history, words can be added without problems.
Comment 31 manj_k 2011-07-04 13:09:16 UTC
@Rainer (Comment #30):
This bug has no bearing on the user-defined dictionaries.
Maybe your user-defined dictionaries are missing, or disabled (missing check marks) in Tools > Options > Language Settings > Writing Aids > User-defined dictionaries; or another root cause.

User profile > registrymodifications.xcu
should show similar items/values as follows:

<item oor:path="/org.openoffice.Office.Linguistic/General/DictionaryList">
 <prop oor:name="ActiveDictionaries" oor:op="fuse">
  <value>
   <it>beats.dic</it> 
   <it>blabla.dic</it> 
   <it>care.dic</it> 
   <it>cuisine.dic</it> 
   <it>intern.dic</it> 
   <it>job.dic</it> 
   <it>names.dic</it> 
   <it>places.dic</it> 
   <it>plus_de.dic</it> 
   <it>plus_en.dic</it> 
   <it>plus_fr.dic</it> 
   <it>standard.dic</it> 
   <it>soffice.dic</it> 
   <it>technical.dic</it> 
   <it>IgnoreAllList</it> 
  </value>
 </prop>
</item>
<item oor:path="/org.openoffice.Office.Linguistic/General/DictionaryList">
 <prop oor:name="IsUseDictionaryList" oor:op="fuse">
  <value>true</value> 
 </prop>
</item>
Comment 32 wope 2011-07-21 11:25:56 UTC
it also happens by an upgrade from 3.4.2rc1 to 3.4.2rc2. This error can't be accepted. I've testet it with Suse 11.4 and Win 7
Comment 33 Thomas Hackert 2011-07-22 20:07:26 UTC
Good morning wope, *,
(In reply to comment #32)
> it also happens by an upgrade from 3.4.2rc1 to 3.4.2rc2. This error can't be
> accepted. I've testet it with Suse 11.4 and Win 7

I have done some testing around your problem and found out, that – if you have installed Karl"s dictionary extension from http://extensions.services.openoffice.org/en/download/5092 –  LO's splashscreen reports something like "disabling dictionary dict-de_DE-frami" at LO's first start (or the like. Roughly translated from German and from my maybe faulty rememberance ... ;) ). If you remove it from the Extension Manager, deinstall LO and reinstall it (maybe this works with an update as well. I have not the time to test it now, sorry ... :( ), all is fine ... ;)

Have you installed the dictionary extension? If so: Would you be so kind to follow my procedure and report back, if it was the problem, please?

But maybe my "solution" is to simple ... ;)
HTH
Thomas.
Comment 34 Helmut Leininger 2011-07-22 22:55:32 UTC
I don't have Karl's extensions installed and it happened nevertheless (win7) when updating from RC1 to RC2.
Comment 35 Rainer Bielefeld Retired 2011-07-22 23:47:29 UTC
(In reply to comment #33)

> installed Karl"s dictionary extension from

I remember to have seen some "disabling dictionary" message in some splash screen. I doubt that I have installed Karl's d.e., but among all those nonsense extensions shipped by default with LibO (I'm really glad to have a Zulu hyphenation dict. on my PC, I need it every day here in Germany) it's not easy to find out. 

I still believe we should reduce No. of dictionaries, especially of installed ones by default, see "Bug 32270 - Only preselect useful dictionaries for Installation".

And for me with "LibreOffice 3.4.1 RC2 - WIN7  Home Premium (64bit) German UI [OOO340m1 (Build:202)]" everything worked fine the last few upgrades.

And, of course, I can't tell what the root of the problem might be.
Comment 36 manj_k 2011-07-23 03:38:26 UTC
(In reply to comment #32)

"disabling <extension xyz>" (shown in the splash screen) is--in that case--the usual process to synchronize the priority of bundled, shared and user extensions (different versions of the same extension, etc.). 

The bug can occur irrespectively of any user-installed dictionary extension (e.g.: see Comment #21).

As far as I can see, the bug will only appear if the older version of the program has been removed/uninstalled before installing the newer version (e.g.: see the tests in Comment #28, Comment #21).
Comment 37 manj_k 2011-07-23 03:42:04 UTC
Correction for comment #36:
false: "(In reply to comment #32)"
true: "(In reply to comment #33)"
Comment 38 vitriol 2011-07-23 03:50:06 UTC
> As far as I can see, the bug will only appear if the older version of the
> program has been removed/uninstalled before installing the newer version (e.g.:
> see the tests in Comment #28, Comment #21).

I have updated the version 3.4.2 RC1 to 3.4.2 RC2 without uninstalling the RC1, and the bug appeared. Replacing the file configmgr.ini fixes lost dictionaries.
This bug in very serious and affects all users that update the software. Releasing a stable version with this bug is absurd...
Comment 39 vitriol 2011-07-23 03:52:19 UTC
(In reply to comment #37)

> false: "(In reply to comment #32)"

It's true, not false. I just tried it under Win7.
Comment 40 Rainer Bielefeld Retired 2011-07-23 04:17:20 UTC
Can we be sure that it's a WIN only problem? If yes, I suggest to consult Tor.
Comment 41 Rainer Bielefeld Retired 2011-07-23 04:18:46 UTC
Hm, AFAIK wope is Linux user
Comment 42 wope 2011-07-23 04:47:08 UTC
I've both, Linux and Win, and this error occured on both OS
deleting the bundle-directory isn't a solution for the users
Comment 43 Rainer Bielefeld Retired 2011-07-23 06:16:11 UTC
REGRESSION because no indication that that happened before 3.4
OS ALL due to comments

> deleting the bundle-directory isn't a solution for the users
I know. For me that's only another annoying usability issue.
Comment 44 wope 2011-07-27 06:26:10 UTC
Now, with 3.4.2rc3, you must delete the user directory, not only the bundles.
This is intolerable. We can't publish a version without spelling
Comment 45 vitriol 2011-08-02 01:37:51 UTC
*** Bug 39731 has been marked as a duplicate of this bug. ***
Comment 46 Jon Grossart 2011-08-02 16:34:51 UTC
This just happened on an upgrade to 3.4.2 from 3.4.1. Vista SP2.  This seems like a big issue for an "enterprise ready" release.  I didn't have this problem on a previous upgrade from 3.3.x to 3.4.1.  Is it just an upgrade issue from 3.4.x to 3.4.x?
Comment 47 vitriol 2011-08-04 11:34:41 UTC
*** Bug 39840 has been marked as a duplicate of this bug. ***
Comment 48 Victor V. Terber 2011-08-04 11:43:55 UTC
(In reply to comment #44)
> This is intolerable. We can't publish a version without spelling
I fully agree.

As this problem was well-known before 3.4.2, it remains an enigma for me why the "enterprise-ready" release was allowed to be shipped.

Very disappointing, and reminding me more deadline-anxious commercial companies than a quality-oriented transparent open-source project.
Comment 49 Urmas 2011-08-08 03:33:30 UTC
*** Bug 39090 has been marked as a duplicate of this bug. ***
Comment 50 tomraymondtom 2011-08-15 17:07:13 UTC
*** Bug 40065 has been marked as a duplicate of this bug. ***
Comment 51 tomraymondtom 2011-08-15 17:10:05 UTC
I Fixed the problem.
1. Uninstalled Libreoffice
2. Scanned C drive for libreoffice and delete all entries found.
3. Reinstalled Libreoffice.
English language 
libreoffice 3.4.2
Windows 7 Ultimate
Comment 52 westley52 2011-08-16 17:46:11 UTC
(In reply to comment #51)
> I Fixed the problem.
> 1. Uninstalled Libreoffice
> 2. Scanned C drive for libreoffice and delete all entries found.
> 3. Reinstalled Libreoffice.
> English language 
> libreoffice 3.4.2
> Windows 7 Ultimate

This does NOT fix the problem.  This method will erase all configurations that a user had made in a prior version.  The problem is that the 'configmgr.ini' is not being properly updated.
Comment 53 Rainer Bielefeld Retired 2011-08-18 11:14:02 UTC
Still a problem with "LibreOffice 3.4.3 RC1  - WIN7  Home Premium (64bit) German UI [OOO340m1 (Build:301)]". Tools -> Optinons -> Language setings -> Writing aids - Available Language modules is empty 

It's becoming a little embarrassing for an "enterprise-ready" office suite. Within 1/4 year no developer as been found as assignee.

@Thorsten:
Can you pleas try to increase developer's interest in this very visible Bug?

Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Comment 54 tomraymondtom 2011-08-18 13:36:45 UTC
(In reply to comment #52)
> (In reply to comment #51)
> > I Fixed the problem.
> > 1. Uninstalled Libreoffice
> > 2. Scanned C drive for libreoffice and delete all entries found.
> > 3. Reinstalled Libreoffice.
> > English language 
> > libreoffice 3.4.2
> > Windows 7 Ultimate
> 
> This does NOT fix the problem.  This method will erase all configurations that
> a user had made in a prior version.  The problem is that the 'configmgr.ini' is
> not being properly updated.

This procedure did fix my spellcheck problem.
Comment 55 wope 2011-08-18 14:07:33 UTC
> 
> This procedure did fix my spellcheck problem.
I know, if I remove the extensions files in the userdirectory, all is ok.
But this is no solution!!!
An user did not know, how to delete this, this are hidden files.
I can't accept this error, therefore, I say to every people, use 3.3.3
Comment 56 wope 2011-08-18 14:41:48 UTC
Addition: by same friends, I've installed macros. I will not go to all the people, to reinstall this
Comment 57 Rainer Bielefeld Retired 2011-08-18 21:21:00 UTC
(Addition to comment #53)

Forgot to mention explicitly:
I did not uninstall 3.4.2, simply installed 3.4.3

Replacing in "configmgr.ini" in C:\Users\user\AppData\Roaming\LibreOffice\3\user\extensions\bundled\registry by file with same name from C:\Program Files (x86)\LibreOffice 3.4\share\prereg\bundled\registry\com.sun.star.comp.deployment.configuration.PackageRegistryBackend healed the problem (hope it will not cause other ones, so I left replaced file as 1Backup_configmgr.ini.
Comment 58 Rainer Bielefeld Retired 2011-08-18 23:06:49 UTC
Unfortunately I still am without a real spell checking, I can't add words to spellcheck any longer (but I am not sure whether that is the result of the problems discussed here or something completely different.

This "Bug 40215 - SPELL: UI broken, impossible to add new words" remains after fallback to 3.4.2
Comment 59 vitriol 2011-08-21 07:24:30 UTC
Another release with this bug is really unacceptable...
Comment 60 vitriol 2011-08-24 11:02:54 UTC
*** Bug 40360 has been marked as a duplicate of this bug. ***
Comment 61 Caolán McNamara 2011-08-25 15:43:42 UTC
Can this problem be reproduced under Linux ? If so, then starting with *no* versions of LibreOffice or OpenOffice.org installed under Linux, what steps must be followed to reproduce the problem ?
Comment 62 Caolán McNamara 2011-08-26 05:11:56 UTC
I bet http://cgit.freedesktop.org/libreoffice/core/commit/?id=5e4c9fb9bbf12b40afbefb30e8d71d6e046b5bd0 is necessary, maybe not sufficient, but probably necessary
Comment 63 vitriol 2011-08-26 05:29:39 UTC
Multiple updating under Windows seems to create multiple subdirectories in the app directory named as lu5za5o.tmp, lu5za6i.tmp, lu5zb1a.tmp and so on.
Every subdirectories contains a different file named dictionaries.xcu.
I suspect that a new upgrade creates a new *.tmp directory and a new dictionaries.xcu file. Perhaps the corresponding configmgr.ini file in the user directory does not reflect the actual change in the app directory.
Comment 64 Rainer Bielefeld Retired 2011-08-26 10:52:41 UTC
(In reply to comment #63)
Your theory matches with my observations. I replaced my profile after upgrade to 3.4.3RC2 by the one I backuped one from RC1, and everything seems to work as expected - except Language Modules.
Comment 65 Andras Timar 2011-08-26 12:26:23 UTC
I created a Windows build from the 3.4.3rc2 + Caolan's patch. You can test it, I'll test it, too.
http://dev-builds.libreoffice.org/fdo37195/LibO_3.4.3rc2_Win_x86_install_multi.exe
Comment 66 wope 2011-08-26 12:50:55 UTC
@Timar: sorry, again the error occured
Comment 67 manj_k 2011-08-26 14:58:49 UTC
The test-build with the patch did not fix the bug for me (on WinXP 32b).
Still the same difference between 'configmgr.ini' (program directory [1]) and 'configmgr.ini' (user profile [2]).
The same workaround as before: replacing the obsolete 'configmgr.ini' (user profile) with a copy of the recent 'configmgr.ini' (LibO program files [share]).

[1] '$BUNDLED_EXTENSIONS_PREREG/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/luegqc3.tmp/dictionaries.xcu', 
etc. (for all 'dictionaries.xcu': starting with 'lueg...', like 'lueg---.tmp')

[2] '$BUNDLED_EXTENSIONS_PREREG/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/ludi8ic.tmp/dictionaries.xcu',
etc. (for all 'dictionaries.xcu': starting with 'ludi...', like 'ludi---.tmp')
Comment 68 Rainer Bielefeld Retired 2011-08-27 00:32:43 UTC
Intention for a test was to check whether fix from Comment 62 brings some progress. 
With my steps 1-4 I checked whether bug still is reproducible for me
With steps 11ff  I checked whether fix eliminates the bug for the same upgrade proceeding
I tested as following, starting ] with installed "LibreOffice 3.4.3 RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]" 

1. Uninstalled 3.4.3
2. deleted (renamed) AppData User Profile
3. Installed 3.4.2 customized for all users and languages de, en + fr + es
   Dictionary access worked as expected 
4. Updated with 3.4.3RC2 
   Dictionaries did not work as expected due to bug
11. So again to step 1 and uninstalled 3.4.3RC2
12. deleted (renamed) AppData User Profile
13. Installed 3.4.2 customized for all users and languages de, en + fr + es
    Dictionary access worked as expected 
14. Upgraded to 3.4.3 with 3.4.3RC2 "Special Edition" from comment 65
    Dictionaries again did NOT work 

So unfortunately I have to confirm wope's, manj_k's result, currently the bug is not fixed.

@manj_k, @wope:
Especially if there is a suspect that a fix only fixes a part of a problem it might be important to know the test conditions for investigations why the problem has not been solved. But currently I believe no more information is required because I can reproduce your unpleasant result.
Comment 69 Caolán McNamara 2011-08-29 07:50:31 UTC
so much for that theory. That said, there is clearly a failure to synchronize/migrate properly.

Here's some extra info, which will hopefully allow some side-by-side debugging of Linux vs Windows...

e.g. with development version, then under Linux...

a) ls -asl .libreoffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/backenddb.xml 

12 -rw-r--r--. 1 caolan caolan 11350 Aug 29 15:43 .libreoffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/backenddb.xml

b) rm .libreoffice/3/user/extensions/bundled/lastsynchronized 

c) /opt/libreoffice3.4/program/soffice.bin

d) ls -asl .libreoffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/backenddb.xml 

12 -rw-r--r--. 1 caolan caolan 11350 Aug 29 15:44 .libreoffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/backenddb.xml

i.e. when lastsynchronized is removed, then the offending backenddb.xml is regenerated completely on the next start

while under Windows...

a) ls -asl /cygdrive/c/Documents\ and\ Settings/caolan/Application\ Data/LibO-de
v/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.configuration
.PackageRegistryBackend/backenddb.xml

4 -rw-r--r-- 1 caolan None 1483 Aug 29 15:02 /cygdrive/c/Documents and Settings/caolan/Application Data/LibO-dev/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/backenddb.xml

b) rm  /cygdrive/c/Documents\ and\ Settings/caolan/Application\ Data/LibO-dev/3/user/extensions/bundled/lastsynchronized

start office

d) ls -asl /cygdrive/c/Documents\ and\ Settings/caolan/Application\ Data/LibO-dev/3/user/extensions/bundled/registrycom.sun.star.comp.deployment.configuration
.PackageRegistryBackend/backenddb.xml

4 -rw-r--r-- 1 caolan None 1483 Aug 29 15:02 /cygdrive/c/Documents and Settings/caolan/Application Data/LibO-dev/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/backenddb.xml

i.e. unchanged, it doesn't regenerate, though the lastsynchronized itself does.

so, to-do is to get desktop built under windows with debugging symbols, add a breakpoint to e.g. places like BackendDb::save and see what that tells us.
Comment 70 Victor V. Terber 2011-08-31 05:12:26 UTC
Is it safe concerning this bug to upgrade from LibreOffice 3.4.2 to 3.4.3, or do I have to expect to go all over this hassles again?
Comment 71 vitriol 2011-08-31 05:21:12 UTC
(In reply to comment #70)
> Is it safe concerning this bug to upgrade from LibreOffice 3.4.2 to 3.4.3, or
> do I have to expect to go all over this hassles again?

This bug also affects the version 3.4.3. Nothing changed.
It's an unacceptable situation.
Comment 72 Tom K 2011-08-31 11:47:22 UTC
Leaving this problem open for 3 months with at least three releases in which to fix it is unacceptable. I just upgraded to 3.4.3 from 3.4.0 and still find this issue. The TDf seems to be interested in pushing out releases but not fixing problems like this regression.
Comment 73 vitruss 2011-09-01 01:23:17 UTC
This is really awful situation when the users have to find the solution and replace some files to make the base functions (spell check is base functions for office suite) work!!!
Comment 74 Caolán McNamara 2011-09-01 02:33:50 UTC
After a couple of false starts with debugging versions, it turns out to be necessary to have an install with a pile (all?) of dictionaries in order to reproduce this, i.e. smaller dev+debugging en-US with just en,fr and de dictionaries isn't sufficient to get the problem.
Comment 75 Caolán McNamara 2011-09-01 04:09:33 UTC
So the copy of
"file:///F:/34-head/share/prereg/bundled/registry/com.sun.star.comp.deployment.component.PackageRegistryBackend/common.rdb"
over
"file:///C:/Users/caolan/AppData/Roaming/LibreOffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.component.PackageRegistryBackend/common.rdb"
fails on windows with error 1224, i.e. ERROR_USER_MAPPED_FILE

this happens in copy_bundled_recursive and any error there halts the recursive copy, so the new backend.xml isn't copied in, so stuck with the pre-upgrade one
Comment 76 Caolán McNamara 2011-09-01 05:32:31 UTC
gotcha I think
Comment 77 Caolán McNamara 2011-09-01 05:58:28 UTC
http://cgit.freedesktop.org/libreoffice/core/commit/?id=a78a6e013b8d97891aa2b9c9a5dce64a82dc2f06

If this theory is correct, then I don't *think* the bug can affect Linux users ?
Comment 78 Rainer Bielefeld Retired 2011-09-01 06:31:37 UTC
@Caolán:
Comment 42 seems to show that also linux users - may be we have several problems causing the same symptoms? To be honest: I completely lost overview concerning this issue. "Bug 40493 - SPELL checker does not work with soffice.exe in non-default folder" also shows effects described here, but only for installation in non default folders.
Any idea how your fix can be tested with a Master build server installation?
Comment 79 Caolán McNamara 2011-09-01 07:15:40 UTC
"re: Comment 42 seems to show that also linux users are affected."
I'd love to get a reproducer for Linux specifically. I'm very unsure about that. If there is a problem I suspect its a different one.


"Any idea how your fix can be tested with a Master build server installation?"

let-me-think: tricky, I'll use my name for simplicity in the examples.

In theory if you were to edit

/Users/caolan/AppData/Roaming/LibreOffice/3/user/extensions/bundled/registryregistry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/backenddb.xml

search for dict-en and change the data-url to some non-existant dir, e.g. change (for me) lu7fsw1.tmp to RANDOM then the en dict should be missing on startup.

what supposed to happen if you then remove

C:/Users/caolan/AppData/Roaming/LibreOffice/3/user/extensions/bundled/registry/lastsynchronized

is that then when you next start LibreOffice its supposed to copy over the stuff from the shared "prereg" dir into the local dir and the dictionaries reappear

It does depend a bit on the *order* that the files are copied in there, the one copied before we encounter "common.rdb" copy fine, the ones after that don't copy seeing as common.rdb cannot be copied. So its a bit of luck the order in which they got copied, I'm not sure if the order is exactly the same between all builds.

Its a pig of a bug basically.
Comment 80 Caolán McNamara 2011-09-01 07:59:39 UTC
*** Bug 40493 has been marked as a duplicate of this bug. ***
Comment 81 Rainer Bielefeld Retired 2011-09-01 10:50:07 UTC
(In reply to comment #79)
That all sounds rather tricky, I believe I will simply do a normal upgrade from 3.4.3 to master and I will see what happens.
Comment 82 Andras Timar 2011-09-01 12:44:42 UTC
(In reply to comment #81)
> (In reply to comment #79)
> That all sounds rather tricky, I believe I will simply do a normal upgrade from
> 3.4.3 to master and I will see what happens.

You can use this as well, a 3.4.3 built with the patch.
http://dev-builds.libreoffice.org/daily/fdo37195/LibO_3.4.3rc2_Win_x86_install_multi.exe
Comment 83 manj_k 2011-09-01 14:33:11 UTC
(In reply to comment #82)
> [...]
> You can use this as well, a 3.4.3 built with the patch.
> http://dev-builds.libreoffice.org/daily/fdo37195/LibO_3.4.3rc2_Win_x86_install_multi.exe

That build with the new patch works fine for me (on WinXP). 
:)

(1)
I applied a user profile 'LibO-test', lastly used with LibO 3.4.3 release.
Installed 'daily/fdo37195/LibO_3.4.3rc2_Win_x86_install_multi.exe' as server image (setup /a); 
modified 'bootstrap.ini': UserInstallation=$SYSUSERCONFIG/LibO-test/3.

'backenddb.xml', 'registered_packages.db', 'configmgr.ini'
in the directory '...\LibO-test\3\user\extensions\bundled\registry\com.sun.star.comp.deployment.configuration.PackageRegistryBackend'
are up-to-date (successfully synchronized)--all bundled dictionaries are available in Writer 'Untitled 1'.

(2)
Removed LibO 3.4.3 RC2_(patch fdo37195).
Installed LibO 3.4.2 release as server image; 
modified bootstrap.ini: UserInstallation=$SYSUSERCONFIG/LibO-test/3.

'backenddb.xml', 'registered_packages.db', 'configmgr.ini'
in the directory '...\LibO-test\3\user\extensions\bundled\registry\com.sun.star.comp.deployment.configuration.PackageRegistryBackend'
with previous values (synchronizing failed)--no available language modules in Writer 'Untitled 1' (Tools > Options ...).

(3)
Removed LibO 3.4.2 final.
Installed 'daily/fdo37195/LibO_3.4.3rc2_Win_x86_install_multi.exe' as server image (setup /a); 
modified 'bootstrap.ini': UserInstallation=$SYSUSERCONFIG/LibO-test/3.

'backenddb.xml', 'registered_packages.db', 'configmgr.ini'
in the directory '...\LibO-test\3\user\extensions\bundled\registry\com.sun.star.comp.deployment.configuration.PackageRegistryBackend'
are up-to-date (successfully synchronized)--all bundled dictionaries are available in Writer 'Untitled 1'.
Comment 84 manj_k 2011-09-01 16:06:05 UTC
(In reply to comment #83)
> 
> (1)
> [...]
> 
> (2)
> Removed LibO 3.4.3 RC2_(patch fdo37195).
> Installed LibO 3.4.2 release as server image; 
> modified bootstrap.ini: UserInstallation=$SYSUSERCONFIG/LibO-test/3.
> 
> 'backenddb.xml', 'registered_packages.db', 'configmgr.ini'
> in the directory
> '...\LibO-test\3\user\extensions\bundled\registry\com.sun.star.comp.deployment.configuration.PackageRegistryBackend'
> with previous values (synchronizing failed)--no available language modules in
> Writer 'Untitled 1' (Tools > Options ...).

Addendum:
Removed the folder 'bundled' [path: '...\LibO-test\3\user\extensions\bundled'].
Restarted LibO 3.4.2 release.

'backenddb.xml', 'registered_packages.db', 'configmgr.ini'
in the directory
'...\LibO-test\3\user\extensions\bundled\registry\com.sun.star.comp.deployment.configuration.PackageRegistryBackend'
are up-to-date (successfully synchronized)--all bundled dictionaries are
available in Writer 'Untitled 1'.

> (3)
> [...]
Comment 85 rpr 2011-09-02 01:08:50 UTC
As vitriol wrote, this bug also occurs after upgrade from 3.4.2 to 3.4.3 (tested on MS Windows XP Pro. SP3 32-bit). The following commands (run in cmd.exe) I used as a workaround:

set subDir="bundled\registry\com.sun.star.comp.deployment.configuration.PackageRegistryBackend"
set source="%ProgramFiles%\LibreOffice 3.4\share\prereg\%subDir%\configmgr.ini"
set destination="%APPDATA%\LibreOffice\3\user\extensions\%subDir%\configmgr.ini"
copy /y %source% %destination%

They suppose LibreOffice was installed in the default destination on the system.

-- rpr.
Comment 86 rpr 2011-09-02 01:17:28 UTC
Created attachment 50837 [details]
CMD script that fixes the issue.
Comment 87 Rainer Bielefeld Retired 2011-09-02 01:49:22 UTC
After all my experience with this tricky bug I am a little conservative with "fixed / all clear", but at least I can say that installation of new LibO_3.4.3rc2_Win_x86_install_multi.exe test build from 
<http://dev-builds.libreoffice.org/daily/fdo37195/> 
did not destroy dictionary access under Win7
Comment 88 paour 2011-09-03 02:01:51 UTC
Hello,
(Windows all versions - Libo 3.4.2 and 3.4.3 - french user)
I deploye Libo in compagny by copiing unique user profil on all session and computer.
This bug seems occur because differences between libo 3.3.x and 3.4.x are in com.sun.star.comp.deployment.configuration.PackageRegistryBackend folder:
1- In Libo 3.3.x, 2nd line in configmgr.ini is specific for user (DATA=$BUNDLED_EXTENSIONS_USER)
2- In Libo 3.4.x, 2nd line is global (DATA=$BUNDLED_EXTENSIONS_PREREG)

As mention above, the workaround is to copy after installation configmgr.ini from %programfile%\(...)\configmgr.ini  to %userdata%\(...)\configmgr.ini 

Why these versions use DATA=$BUNDLED_EXTENSIONS_PREREG instead of DATA=$BUNDLED_EXTENSIONS_USER.

Please resolve this bug .
Txs
Nicolas
Comment 89 Rainer Bielefeld Retired 2011-09-06 23:33:58 UTC
<http://wiki.documentfoundation.org/BugReport_Details#Version>
Comment 90 Caolán McNamara 2011-09-07 03:10:45 UTC
http://cgit.freedesktop.org/libreoffice/libs-core/commit/?h=libreoffice-3-4&id=53714706ae6c8dad65e7dfed124c065fea1e10f9 now in place for next 3-4

Anyone adding additional comments that add no new information will be strangled with their own intestines
Comment 91 vitriol 2011-09-07 11:13:00 UTC
*** Bug 40691 has been marked as a duplicate of this bug. ***
Comment 92 Rainer Bielefeld Retired 2011-09-27 04:06:06 UTC
*** Bug 41241 has been marked as a duplicate of this bug. ***
Comment 93 Susan Cragin 2011-10-03 05:41:33 UTC
This bug is back as of the October 1 Daily Build. 
12.06.37
Comment 94 Rainer Bielefeld Retired 2011-10-03 10:28:08 UTC
That's a Master build from /Linux_x86_64_Release_Configuration/master/

@Susan Cragin
Did you check all indications of the bug (bootstrap.ini, registrymodifications.xcu, ...) or did you only see the effect (no spell check)?

It's useful if you contribute the complete build identifier and the source from where you got the build.

Is this something different than "Bug 41290 - dictionaries do not install in daily builds as of 28/9/2011"?
Comment 95 Rainer Meier 2011-10-10 09:36:56 UTC
Created attachment 52186 [details]
Fix to be execute in user-space (Windows only)

I had some customers running into this issue with LO 3.4.3 and found this thread. There was a script provided which can be executed by users to fix the issue in their profile. This script did not work on Windows x64 so I've extended it.

Tested on Windows 7 x64.
Comment 96 Ð 2011-10-12 11:26:31 UTC
Comment on attachment 52186 [details]
Fix to be execute in user-space (Windows only)

Whereto should this Fix be applied/placed?
Comment 97 Rainer Bielefeld Retired 2011-10-27 23:25:07 UTC
Will the fix (IMHO in 3.4.4?) also heal damaged installations or only prevent from getting the problem if dictionary access works in installation before upgrade?
Comment 98 manj_k 2011-10-28 08:32:28 UTC
(In reply to comment #90)
> http://cgit.freedesktop.org/libreoffice/libs-core/commit/?h=libreoffice-3-4&id=53714706ae6c8dad65e7dfed124c065fea1e10f9
> now in place for next 3-4 [...]

Bugfix verified with LibO 3.4.4 RC1 on WinXP
[LibreOffice 3.4.4 OOO340m1 (Build:401)].

1. Installed a server image of LibO 3.4.4 RC1 and applied the user profile of LibO 3.4.3 release 
[the same 'bootstrap.ini': UserInstallation=$SYSUSERCONFIG/LibO-34/3].

2. Applied also some older directories '...\user\extensions\bundled'.

Synchronizing and registering the current bundled dictionaries works fine.
Comment 99 Kelsey 2011-12-04 14:13:58 UTC
Look...I'm only a lowly user...not a programmer. When will an official build release be available with this bug totally gone? Just upgraded to 3.4.4 (OOO340m1 (Build:402)) a few days ago and it's still here. I'm running Vista 32 bit.
Mucking around with my setup I think I've lost my user-added dictionary while trying to perform some of the hacks listed here.
This is since when? May??? C'mon!!!!!
Comment 100 mike.hall 2011-12-04 22:56:48 UTC
@Kelsey
Works for me with #3.4.4. Actually, it was fixed for previous version too after applying the fix in comment #95. You might try that and see if it works for you.
Comment 101 Björn Michaelsen 2011-12-23 13:25:52 UTC
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
Comment 102 Xisco Faulí 2018-02-26 11:19:08 UTC
The content of attachment 48257 [details] has been deleted