Bug Hunting Session
Bug 67555 - Adding a word to a custom dictionary overwrites NTFS symbolic link to dictionary
Summary: Adding a word to a custom dictionary overwrites NTFS symbolic link to dictionary
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Linguistic (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: x86-64 (AMD64) Windows (All)
: medium enhancement
Assignee: Caolán McNamara
URL:
Whiteboard: target:5.3.0
Keywords: preBibisect, regression
Depends on:
Blocks:
 
Reported: 2013-07-30 18:41 UTC by Jon Grossart
Modified: 2016-09-29 19:52 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jon Grossart 2013-07-30 18:41:27 UTC
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.
Comment 1 Urmas 2013-07-31 04:52:36 UTC
This is because a new file is creating each time it is modified.

As a work-around, try to link the entire 'workbook' directory.
Comment 2 Jon Grossart 2013-08-01 05:38:38 UTC
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.
Comment 3 Andras Timar 2013-08-07 12:11:36 UTC
The behaviour changed due to fix of bug 42122. The relevant commit is 28300209604ee1bb8e5050322b29e95a07f679d8.
Comment 4 Michael Meeks 2013-08-07 12:50:19 UTC
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.
Comment 5 Jon Grossart 2013-08-07 16:41:46 UTC
(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?
Comment 6 Jon Grossart 2013-08-07 16:47:20 UTC
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.
Comment 7 Jon Grossart 2013-08-07 20:23:25 UTC
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.
Comment 8 Andras Timar 2013-08-08 05:44:53 UTC
> 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.
Comment 9 retired 2014-12-11 10:28:10 UTC
Jon, does the workaround Andras mentions in comment 8 work for you?
Comment 10 Jon Grossart 2014-12-12 19:37:58 UTC
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.
Comment 11 Robinson Tryon (qubit) 2015-02-19 00:34:27 UTC
(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.
Comment 12 Robinson Tryon (qubit) 2015-12-10 01:26:23 UTC Comment hidden (obsolete)
Comment 13 Xisco Faulí 2016-09-13 10:53:59 UTC
This regression was introduced before branch 4.4, thus it can't be bibisected with the current bibisect repositories. Changing keyword 'notBibisectable' to 'preBibisect'
Comment 14 Commit Notification 2016-09-29 16:26:36 UTC
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.