Since it's not possible to add a user-specified directory for user dictionaries (bug 36558), I use NTFS symbolic links to reference wordbooks elsewhere in my directory tree (somewhere that gets backed up and synced). These can be created using "mklink LINK TARGET" in an admin command prompt. Up to LO 4.0.4, this worked perfectly fine. However, in LO 4.1.0, something changed in the implementation. Now, if I add a new word to my custom dictionary, the file gets written to the {user}/AppData/Roaming/LibreOffice/4/user/wordbook directory and it overwrites the symbolic link, rather than writing it to the linked file.
This is because a new file is creating each time it is modified. As a work-around, try to link the entire 'workbook' directory.
It's not an enhancement. It's a regression. The behavior changed from <4.0.4 to 4.1 It used to work how it should -- the new file was written honoring the symbolic link. Now, it overwrites the symbolic link. That is a bug.
The behaviour changed due to fix of bug 42122. The relevant commit is 28300209604ee1bb8e5050322b29e95a07f679d8.
A whole lot of commits to: git log -u linguistic/source/dicimp.cxx which is where the issue will be, including Michael Stahl's fix of my fix :-) It's somewhat unclear to me that putting arbitrary symbolic links into your home directory is something that we can support. The atomic overwrite of those files is important for not (ever) loosing data while writing, I guess we could try to move the operation into the linktarget in this case but ... Patches much appreciated.
(In reply to comment #4) > It's somewhat unclear to me that putting arbitrary symbolic links into your > home directory is something that we can support. Actually, I don't disagree. Using symbolic links is sort of hack anyway (especially for NTFS). My concern is that it worked fine until 4.1. In all actuality, I think the feature request I made in 36558 is the real solution. If the user can specify where to put templates and other such user specific items, why can't the user add directories to search for custom dictionaries. Wouldn't this also be needed in corporate offices where they might make a custom workplace wide dictionary that everyone needs to pull in and might be updated more often than a corporate controlled reinstall?
And I guess the other point might (and perhaps unrelated to a direct LibO fix and maybe on of the support libraries), why is a file overwrite ignoring the symbolic link and overwriting instead. I would think that the file write should honor that link transparently to LibO, as I assume it would in Linux as well. That being said, I doubt symbolic links in NTFS are all that well supported, as they are fairly uncommon.
I just checking in an Ubuntu 13.04 VM using LibO 4.0.4.2 works as expected with symbolic link. LibO 4.1.0.4 also works as expected with symbolic link. (installed from LibO PPA). So, the change seems to have only affected the Windows version with NTFS symbolic links.
> Since it's not possible to add a user-specified directory for user dictionaries (bug 36558) It's been always possible to set this property, although not from the GUI. But you can always edit registrymodifications.xcu. E.g. I set my dictionary path to my home directory in the example below. <item oor:path="/org.openoffice.Office.Paths/Paths/org.openoffice.Office.Paths:NamedPath['Dictionary']"><prop oor:name="UserPaths" oor:op="fuse"><value></value></prop></item> <item oor:path="/org.openoffice.Office.Paths/Paths/org.openoffice.Office.Paths:NamedPath['Dictionary']"><prop oor:name="WritePath" oor:op="fuse"><value>$(home)</value></prop></item> Nevertheless, I fixed bug 36558, so you can set it up from GUI, too.
Jon, does the workaround Andras mentions in comment 8 work for you?
Well, I didn't do the workaround, but Andreas added in the GUI support to change it directly. So, the overall problem is solved. However, there would still be a bug/regression of why it changed behavior of overwriting the symbolic link rather than using it. It should honor a symlink setup in the filesystem. Granted, now it would be a minor issue, as not many people use symlinks on NTFS, and the GUI solution is "more correct" anyway.
(In reply to Andras Timar from comment #3) > The behaviour changed due to fix of bug 42122. The relevant commit is > 28300209604ee1bb8e5050322b29e95a07f679d8. Sounds like the behavior is confirmed with this commit, so changing status from UNCONFIRMED to NEW.
Migrating Whiteboard tags to Keywords: (notBibisectable)
This regression was introduced before branch 4.4, thus it can't be bibisected with the current bibisect repositories. Changing keyword 'notBibisectable' to 'preBibisect'
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a8f32f34b68d9368db5371c0889e7b5955b5a10f Resolves: tdf#67555 writeFile honors ntfs symlinks as it turns out It will be available in 5.3.0. 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.