Bug Hunting Session
Bug 122399 - File Locking (on by default) Cannot Be Turned Off in LibreOffice Versions 5 & 6 for Mac by modifying soffice file
Summary: File Locking (on by default) Cannot Be Turned Off in LibreOffice Versions 5 &...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.1.4.2 release
Hardware: x86-64 (AMD64) Mac OS X (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: File-Lock
  Show dependency treegraph
 
Reported: 2019-01-01 08:10 UTC by glen
Modified: 2019-01-04 18:57 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Readme file containing directions for turning off file locking in the Mac version of LibreOffice (13.78 KB, text/plain)
2019-01-01 08:10 UTC, glen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description glen 2019-01-01 08:10:20 UTC
Created attachment 147915 [details]
Readme file containing directions for turning off file locking in the Mac version of LibreOffice

File Locking cannot be turned off as per directions given in the ReadMe file that accompanies the installer for Mac version 6.1.4.2 of LibreOffice. This is also true for version 5.x.x.x for Mac. 

The negative effects are: 

1) a file cannot be edited on both of two machines that are owned by the same user. 

2) likewise, files cannot be edited by two Mac users who share files using different machines and/or user accounts.

According to the README_en-US file that accompanies the LibreOffice installer:

To disable file locking, edit the soffice script and change the line "export SAL_ENABLE_FILE_LOCKING" to "# export SAL_ENABLE_FILE_LOCKING".

The problem appears to be either the incomplete filename, referred to above as 'the soffice script'; or the nature of the soffice file itself, which is located in:

Applications-->LibreOffice-->Content-->MacOS--'soffice'

Perhaps this is not the actual file being referenced by the directions. If it is not, the directions need to be corrected to give the actual filename of the script file, and ideally, the precise location of the file that needs to be edited.

If the soffice file itself needs to be altered, the directions should deal with the fact that it is a binary file which cannot be read or edited by a text editor.

The complete Readme file is attached herein.
Comment 1 Alex Thurgood 2019-01-04 09:53:41 UTC
@Glen: you are correct. It has actually been this way for a while, but I guess most people don't try and change the behaviour on macOS.

The soffice file is a binary executable on macOS, thus editing it as suggested by the README won't work. I don't actually know what the solution to this might be, other than possibly having a info.plist parameter, or maybe modifying one of the rc files in the Resources folder of the app bundle.

Confirming.
Comment 2 Alex Thurgood 2019-01-04 09:57:26 UTC
Actually, I guess that starting LO from the terminal in which you have preceded the file path to the soffice executable with the "export SAL_ENABLE_FILE_LOCKING=0" in your ENV might work.
Comment 3 Alex Thurgood 2019-01-04 09:58:16 UTC
@cloph : any ideas about this ?
Comment 4 glen 2019-01-04 18:22:41 UTC
Hi Guys—

Thanks for thinking about this bug report.

Actually, someone on the LO forum directed me to Expert Configuration in the Preferences pane.

There, a search on 'lock' turns up three parameters (lebeled 'misc') that, if set to false, disables automatic file locking. This lets me (or anyone) open and edit LO files on various machines and user accounts, which is a good thing. 

I have a Mac tower at home and carry a Mac laptop most places I go, sharing files between them via Dropbox. Before I realized how to turn off file locking, in LO and also AOO, it was not possible to edit a file on the machine it was not created on. Sometimes I could not even open a file on the other machine!

I put in this bug report because in the Bug Reporting FAQ I was advised that behaviors that are unexpected or too difficult to deal with are valid topics for bug reports. The mis-information in the Readme file leads the user to waste time and get frustrated trying to put the erroneous advice into effect. 

Simply re-writing the Readme file to direct Mac users to Preferences-->Advanced-->Expert Configuratin, then search 'lock' and define the parameters as 'false', would solve the problem as I encountered it.