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
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
Created attachment 46705 [details] my language settings
- 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
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.
Created attachment 46712 [details] Broken spell check – screenshot 'missing_dicts_libo340b5.png'
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).
Created attachment 46720 [details] Screenshot: User profile Beta 4 - broken
Created attachment 46721 [details] Screenshot: User profile Beta 3 - OK
(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'.
*** Bug 37439 has been marked as a duplicate of this bug. ***
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!
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.
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
*** Bug 38500 has been marked as a duplicate of this bug. ***
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')
Created attachment 48214 [details] Screenshot 1: No available language modules
Created attachment 48215 [details] Screenshot 2: All bundled dictionaries are available.
Created attachment 48216 [details] Renamed folder 'bundled_old_7'
Created attachment 48217 [details] New folder 'bundled'
It's unacceptable that an upgrade destroys the existing configuration.
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.
Created attachment 48257 [details] Comparison: registrymodifications.xcu_1–3.xcu [zip archive]
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?
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'
Created attachment 48301 [details] obsolete file 'configmgr.ini' (user profile)
Created attachment 48302 [details] current file 'configmgr.ini' (program folder)
@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.
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)
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.
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.
@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>
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
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.
I don't have Karl's extensions installed and it happened nevertheless (win7) when updating from RC1 to RC2.
(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.
(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).
Correction for comment #36: false: "(In reply to comment #32)" true: "(In reply to comment #33)"
> 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...
(In reply to comment #37) > false: "(In reply to comment #32)" It's true, not false. I just tried it under Win7.
Can we be sure that it's a WIN only problem? If yes, I suggest to consult Tor.
Hm, AFAIK wope is Linux user
I've both, Linux and Win, and this error occured on both OS deleting the bundle-directory isn't a solution for the users
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.
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
*** Bug 39731 has been marked as a duplicate of this bug. ***
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?
*** Bug 39840 has been marked as a duplicate of this bug. ***
(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.
*** Bug 39090 has been marked as a duplicate of this bug. ***
*** Bug 40065 has been marked as a duplicate of this bug. ***
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
(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.
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.
(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.
> > 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
Addition: by same friends, I've installed macros. I will not go to all the people, to reinstall this
(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.
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
Another release with this bug is really unacceptable...
*** Bug 40360 has been marked as a duplicate of this bug. ***
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 ?
I bet http://cgit.freedesktop.org/libreoffice/core/commit/?id=5e4c9fb9bbf12b40afbefb30e8d71d6e046b5bd0 is necessary, maybe not sufficient, but probably necessary
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.
(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.
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
@Timar: sorry, again the error occured
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')
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.
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.
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?
(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.
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.
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!!!
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.
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
gotcha I think
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 ?
@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?
"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.
*** Bug 40493 has been marked as a duplicate of this bug. ***
(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.
(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
(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'.
(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) > [...]
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.
Created attachment 50837 [details] CMD script that fixes the issue.
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
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
<http://wiki.documentfoundation.org/BugReport_Details#Version>
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
*** Bug 40691 has been marked as a duplicate of this bug. ***
*** Bug 41241 has been marked as a duplicate of this bug. ***
This bug is back as of the October 1 Daily Build. 12.06.37
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"?
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 on attachment 52186 [details] Fix to be execute in user-space (Windows only) Whereto should this Fix be applied/placed?
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?
(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.
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!!!!!
@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.
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.
The content of attachment 48257 [details] has been deleted