Help sought for configuring LibreOffice to respect File System Shortcuts

English
#1

I have a PC that dual-boots between Mint Linux and Windows 11 - I have to have Windows for work purposes, but I tend to use Linux for everything else. Because it supports both platforms, I use LibreOffice as my office productivity suite of choice.

One of the things I’d like to use LibreOffice for requires me to use Custom Dictionaries… However, the key thing here is that I want to be able to share the same custom dictionary file[s], irrespective of which operating system I am running.

I’ve done some basic exploration/digging and come up with the following:-

On Mint Linux, LibreOffice stores custom dictionaries in the following location:-

/home/{user}/.config/libreoffice/4/user/wordbook/

On Windows 11, LibreOffice stores custom dictionaries in the following location:-

c:\Users{user}\AppData\Roaming\LibreOffice\4\user\wordbook\

I also happen to have a QNAP NAS, so on my Linux build I renamed the “wordbook” folder to “wordbook_orig” and I created a symbolic link to a copy of the folder on my NAS. It works perfectly - when I boot in to Linux and launch LibreOffice Writer, it spell checks perfectly using the network-hosted copy of my custom dictionary file…

On windows, I can then go to the /4/user/ folder and I rename the default “wordbook” folder to “wordbook_orig”… I then right-click in Windows Explorer and select “New” and “Shortcut”… and I plug in the details that take me to the exact same location on my NAS.

At first glance, everything looks OK.

However, I can run LibreOffice perfectly on Linux, but when I try the same thing on Windows, the program still launches, but it does not seem to see or import my custom dictionary. If I then go to …

\AppData\Roaming\LibreOffice\4\user,

I then see that the running binary has created a new local copy of “wordbook” - so the “user” folder now contains 2 entries named “wordbook”, except that one is my symbolic link and the other is a recreated local folder, put there by the LibreOffice binary.

I’d be very grateful if anyone can suggest any reason why LibreOffice isn’t respecting symbolic links - and if so, whether there might be a runtime flag or other parameter I could set in order to force it to do so, such that I can share my dictionary between Linux and Windows versions.

Thanks in advance for any suggestions you can make.

#2

I’d say the main problem is a Windows shortcut being something else than a file. Compare here:

https://superuser.com/questions/253935/what-is-the-difference-between-symbolic-link-and-shortcut

I didn’t try this, but it is possible in Windows to mount a network share as a folder on a ntfs-drive. Maybe this could solve your problem…

#3

Thank you very much for responding.

I think it’s probably fair to say that I walked myself in to this - I also use Thunderbird as my email client of choice… and I was able to use a Windows Shortcut to allow me to move my entire profile for that application to my NAS.

As you point out, it looks as though Thunderbird is “shortcut-aware” and LibreOffice is not.

I will experiment with the suggestion to mount a network share on a folder - and if that works I will come back and add a confirmation for future readers.

Thank you

#4

My guess is, one can hide this in libraries.

That would be nice.

#5

OK, here’s an interim though unsuccessful update. I’ve created a new share on my NAS which exports directly from the \wordbook folder. I’ve tested mounting that to a drive letter and that works perfectly.

Next, I need to mount that exported share to a specific folder on my C: drive. I had a look around and found guidance to do that on SuperUser:-

https://superuser.com/questions/244562/how-do-i-mount-a-network-drive-to-a-folder

However, when I try and follow that guidance, I’m only partly successful. First step is to access the share:-

net use \TVS672XT\wordbook

That returns, “The command completed successfully.”

Then,

'mklink /d “c:\Users\sad_b\AppData\Roaming\LibreOffice\4\user\wordbook” \TVS672XT\wordbook"

That results in an error: “You do not have sufficient privilege to perform this operation.”

I went back and checked to see if I have the ability to launch the Windows Command Prompt from the menu with a right-click and “Run as Administrator”, but that option isn’t available to me. So instead I launched PowerShell and tried again. This time, the initial “net use” command works successfully but give me a set of useful diagnostic data, but I get more detail with the next command:-

mklink /d “c:\Users\sad_b\AppData\Roaming\LibreOffice\4\User\wordbook” \TVS672XT\wordbook
mklink : The term ‘mklink’ is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1

  • mklink /d "c:\Users\sad_b\AppData\Roaming\LibreOffice\4\User\wordbook …
  •   + CategoryInfo          : ObjectNotFound: (mklink:String) [], CommandNotFoundException
  + FullyQualifiedErrorId : CommandNotFoundException

That tells me that I can’t access the mklink command from Powershell, so it looks as though the only option I have would be to add my default user to the “Local Admin” group and try again.

I’m going to try that next, but the key thing for me here is that I absolutely will not leave my regular UserID as a member of the Local Admin group - it’s just not safe to do that. But if I can get the mount created and then access it using normal permissions, this might be a solution.

At first I thought that the “mklink” command would be no better than trying to use Windows Explorer… but in the documentation, which I found here

I see that the command line option of this command has the “/h” parameter, which the notes say, “Creates a hard link instead of a symbolic link”. If that’s true, then that might be what LibreOffice needs to respect and follow the link to my NAS…

Any thoughts on the “permissions” complication would be gratefully received…

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.