Created attachment 52646 [details] user-defined dictionary to reproduce the bug The deletion of words from a user-defined dictionary does not work properly using the UI given at Tools > Options > Language Settings > Writinge Aids. STEPS TO REPRODUCE 1) Go to "Writing Aids" 2) Create a new Dictionary (e.g. with the name "test", all languages) 3) Edit "test" 4) Add the words "zappy" and "xappy" 5) Hit "Close", hit "OK". test.dic now looks this way: OOoUserDict1 lang: <none> type: positive --- xappy zappy 6) Reopen "Writing Aids" 7) Remove xappy 8) Hit "Close", hit "OK". test.dic now looks this way: OOoUserDict1 lang: <none> type: positive --- zappy zappy ANOTHER EXAMPLE This bug also applies to already existing user dictionaries. Deleting a randaom word from the attached dictionary ends at some confusion around the last few lines. Before: ... Özdogan Özdogans äsopische After deleting the entry "Agamben" (hit "Close" and "OK") the file ending looks like this: ... Özdogan Özdogans äsopische opische After deleting another entry (for this example "Ahasveros"; hit "Close" and "OK") seems to corrupt the file totally. After that, for some reasons my plain text editor does not recognize anymore that the file is UTF8-encoded (also another line has been added): ... Ãzdogan Ãzdogans Àsopische €sopische opische
I can confirm that behavior (the described 'STEPS TO REPRODUCE': xappy/zappy) with LibO 3.4.3 release on WinXP. Another test with an existing user-defined dictionary (Language: German(Germany)) resulted in messed up entries at the end of the dictionary. Sample: lines 220–229 ungebeugt unterfinanziert wortübergreifende zitierbar nziert wegsortieren wortübergreifende zitierbar zitierbar
I just noticed the same broken behavior in LO 3.6.4.3 on Windows 7 x64, so instead of filing a new bug I'm updating the version on this one to that release.
Version reset to '3.4.3 release'. @ Tino Didriksen Thanks for your verification. Please have a look at https://wiki.documentfoundation.org/BugReport_Details#Version .
*** Bug 61058 has been marked as a duplicate of this bug. ***
Apparently caused by commit 7e01bc8d28ffefd4539a5eae2587e1f7da0999e7
I have a prototype fix on my machine that needs some testing; doing it right is > a 1 line fix. Thanks for the commit hash Urmas ! - nice to know the bug was there since 2009 ;-)
re-written to write the dictionary to a .dic.tmp file and ~atomically move it over the .dic file IFF we write it correctly - this avoids several potentials for corruption / loss of the existing data if out-of-space etc. It also fixes the truncation issue pretty categorically. If people can test and verify that that works in a master build - I'll try to find someone to pick it for 4.0.2. Thanks for reporting !
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=28300209604ee1bb8e5050322b29e95a07f679d8 fdo#42122 - truncate files that shrink to avoid dictionary corruption. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
@Michael: I'll check the upcoming daily build and give you a hint whether the patch works for me or not. Thank's for fixing it!
Unfortunately, I'm not able to start the current master build (it terminates with a shared library error). So I guess we'll have to wait until 4.1 to enjoy the working fix. :(
@Nico Dorn 4.1 RC1 is available and should have that fix. http://www.libreoffice.org/download/pre-releases/ please test it, and if it works ask for backporting into 4.0.5
*** Bug 65992 has been marked as a duplicate of this bug. ***
Your wish is my command :) I tested the examples posted by me in the first comment and the cases in Bug 65992 with LO 4.1.0.1. Works like a charm, good work Michael! Please backport the fix to 4.0.5. Thanks!
(In reply to comment #11) > @Nico Dorn > 4.1 RC1 is available and should have that fix. > http://www.libreoffice.org/download/pre-releases/ > > please test it, and if it works ask for backporting into 4.0.5 I can also confirm this bug. Additionally to the corruption it also prohibits the last word from the user-dictionary to be removed. Although I cannot confirm the fix since the current beta of LibreOffice 4.1.0.1.0 from 27.06.2013 (Build ID: 8a1cc1449c26b7b5a46f258aabf13c28a9dbebb) crashes after closing if you have created an user-dictionary by adding a new word (like "xappy") after a clean installation. OS is Windows XP SP3. The crashes might be related to the fix.
(In reply to comment #14) > Although I cannot confirm the fix since the current beta of LibreOffice > 4.1.0.1.0 from 27.06.2013 (Build ID: > 8a1cc1449c26b7b5a46f258aabf13c28a9dbebb) crashes after closing if you have > created an user-dictionary by adding a new word (like "xappy") after a clean > installation. OS is Windows XP SP3. The crashes might be related to the fix. I'm not facing any crash at all (Kubuntu 12.10, LO 4.1.0.1 Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155). I think you should open a new bug and link to this one.
(In reply to comment #15) > (In reply to comment #14) > > > Although I cannot confirm the fix since the current beta of LibreOffice > > 4.1.0.1.0 from 27.06.2013 (Build ID: > > 8a1cc1449c26b7b5a46f258aabf13c28a9dbebb) crashes after closing if you have > > created an user-dictionary by adding a new word (like "xappy") after a clean > > installation. OS is Windows XP SP3. The crashes might be related to the fix. > > I'm not facing any crash at all (Kubuntu 12.10, LO 4.1.0.1 > Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155). I think you should open > a new bug and link to this one. Done: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=66420
the fix for this bug introduced bug 66420