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:
6) Reopen "Writing Aids"
7) Remove xappy
8) Hit "Close", hit "OK". test.dic now looks this way:
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:
After deleting the entry "Agamben" (hit "Close" and "OK") the file ending looks like this:
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):
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
I just noticed the same broken behavior in LO 22.214.171.124 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
*** 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":
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:
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. :(
4.1 RC1 is available and should have that fix.
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 126.96.36.199. 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.
> 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 188.8.131.52.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
> 184.108.40.206.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 220.127.116.11
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
> > 18.104.22.168.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 22.214.171.124
> Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155). I think you should open
> a new bug and link to this one.
the fix for this bug introduced bug 66420