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) macOS (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: 2023-01-20 03:24 UTC (History)
3 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.
Comment 5 QA Administrators 2021-01-04 04:05:36 UTC Comment hidden (obsolete)
Comment 6 Louis Steinberg 2021-01-18 19:08:15 UTC
  (In reply to glen from comment #4)
Hi Glen.  I tried this in 7.2.0.0 and the search for "lock" turned up pages and pages of parameters, mostly things with names that include "block" or "clock". 

The simplest solution seems to me to be to make it clearer in the README that the file locking section only applies to linux (and Windows if that is true).
 
> 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.
Comment 7 glen 2021-01-19 00:02:53 UTC
Louis—

Thanks for thinking about this.

My experinece with L.O. running on macOS was that locking was implemented by default. That meant that documents created on my laptop could not be opened on my desktop machine, and vice versa.

I did eventually learn how to turn file locking off, though the process of navigating multiple layers of advanced preferences will probably be beyond the knowledge and incliniations of many users. I think I turned off security measures in at least three places to get the programs to behave normally.

If it is possible to put file locking to 'off' by default it would avert this kind of inconvenience and confusion. If that is an unrealistic expectation, the next best thing might be to include exact instructions for turning it off and on in the READme file.

Written au natural by a health freedom loving American,

Glen
Comment 8 Louis Steinberg 2021-01-19 01:56:34 UTC
Glen:

I am really (really!) not the one to say how locking should behave in L.O., and I don't know how it does behave, but I am surprised that it prevents you from creating a file on one machine, closing it there, and opening it on the other machine. Perhaps it is due to some feature of how Dropbox works.  

Assuming that the behavior is not changed, at least I would recommend clarifying in the README that the discussion of changing the default only applies to Linux (and Windows if it does).

Everyone:  How should I go about recommending that change to the README?

Lou
Comment 9 glen 2021-01-19 07:10:29 UTC
If this thread applies to my report, it has nothing to do with Linux or Windows. It has to do with the Mac.
Comment 10 QA Administrators 2023-01-20 03:24:52 UTC
Dear glen,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug