Bug 41442 - Control File Locking from Options
Summary: Control File Locking from Options
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 51546 54876 123862 (view as bug list)
Depends on:
Blocks: Options-Dialog File-Lock
  Show dependency treegraph
 
Reported: 2011-10-04 04:06 UTC by sqrtyl
Modified: 2020-09-04 08:37 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
/usr/lib/libreoffice/share/registry/disable-file-locking.xcd (362 bytes, application/xml)
2015-01-11 19:26 UTC, Marcel Partap
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sqrtyl 2011-10-04 04:06:47 UTC
Add an option in the options dialog to control file locking.


Rationale.
There are a reasonable number of posts on the web asking about how to disable or control OO file locking, under windows, linux, etc.

Some people have problems with locks preventing them from accessing documents. I (and most likely some others) do not wish to have the lockfiles themselves because they clutter directories and get copied to backups and release directories if not manually removed.

While there are supposedly methods to control file locking using environment variables, I and others can't get them to work.
http://www.oooforum.org/forum/viewtopic.phtml?t=131492

Even if they worked, I believe environment variables are a poor way to control functionality. This feature is in the same class of features as autosave, which is controlled via the options dialog.

There are good reasons for using lock files, especially within multi-user environments. But there are good reasons why some people don't want them, which is why the lock-controlling environment variables exist.



Here are my suggestions.

Add the option to either of these dialogs:
Tools->Options->LibreOffice->General.
Tools->Options->Load/Save->General.


Option 1: (My choice).

File Locking.
Tickbox "enable file locking" (on by default).
Deselecting this prevents the _creation_ and checking of lock files.


Option 2: (If for some reason people actually want to create the lock files but not use them as locks, no idea if anybody actually wants this, but some programs do this).

File Locking.
Tickbox "create lock-files" (on by default).
Deselecting this prevents the _creation_ of lock files.

Tickbox "check lock-files" (on by default), possibly greyed out if "create lock files" is disabled.
Deselecting this prevents checking of lock files when opening.



This should be a fairly quick enhancement to write, as the functionality exists via environment variables.
Comment 1 Björn Michaelsen 2011-12-23 12:41:27 UTC Comment hidden (obsolete)
Comment 2 Florian Reisinger 2012-08-14 14:00:45 UTC Comment hidden (obsolete)
Comment 3 Florian Reisinger 2012-08-14 14:01:52 UTC Comment hidden (obsolete)
Comment 4 Florian Reisinger 2012-08-14 14:06:34 UTC Comment hidden (obsolete)
Comment 5 Florian Reisinger 2012-08-14 14:08:36 UTC Comment hidden (obsolete)
Comment 6 Andrzej Hunt 2012-09-21 13:14:12 UTC
*** Bug 54876 has been marked as a duplicate of this bug. ***
Comment 7 Andrzej Hunt 2012-09-21 13:16:35 UTC
(Reopening as there are still requests being made to allow disabling of lock files.)
Comment 8 Joel Madero 2012-10-16 21:10:01 UTC
This seems like a feasible enhancement request. Going to go ahead and confirm the request, I don't know how easy it will be to implement but marking as a low level enhancement request.

Rationale: Not many people will ever use the feature to disable the ability to lock files. Also, not sure how one would accidentally lock a file and then another person not want it locked (if I'm understanding this correctly). The simple thing to do is just not lock files. In a corporate setting I can see the feature being a little more useful.

Thanks for putting in the request
Comment 9 bfoman (inactive) 2013-01-21 16:53:58 UTC
*** Bug 51546 has been marked as a duplicate of this bug. ***
Comment 10 Roger Heflin 2013-04-22 02:11:16 UTC
(In reply to comment #8)
> This seems like a feasible enhancement request. Going to go ahead and
> confirm the request, I don't know how easy it will be to implement but
> marking as a low level enhancement request.
> 
> Rationale: Not many people will ever use the feature to disable the ability
> to lock files. Also, not sure how one would accidentally lock a file and
> then another person not want it locked (if I'm understanding this
> correctly). The simple thing to do is just not lock files. In a corporate
> setting I can see the feature being a little more useful.
> 
> Thanks for putting in the request

Lock files only work in a *PERFECT* world te way they are implemented in openoffice, and there is no what to easily fix things if that *PERFECT* world fails.

Situation: machine opens a file on an NFS mount, office locks the file.  Office crashes, machine crashes or machine runs out of battery, X windows crashs...probably other possible things that can happen...lock is left on NFS server orphaned with no chance of reclaim/releasing/removing the lock without using other tools to clear the file or copying the file to a new name and working on it, or rebooting things in the correct manner.

Suggest when complaining about a lock existing on a file you need to explain and/or give a way to clear/reset/bypass the lock.   Office appears to have at least 2 different methods and neither of the methods indicate how to reset the lock (the *LCK file and the nfs locks), or give a way to reset the lock if the user in question has the privs needed to reset the lock. 

I have successfully cleared NFS locks but it takes an expert to even figure out that is what is going wrong as nothing indicates which manner of locking is being used.

There does not appear to be a way to disable this badly implemented/poorly though out feature when the world is less than perfect, and there is no easy way to clear/reclaim/remove a lock once office has applied it.

And if you disable NFS locking (at the NFS level) office refuses to open anything as it cannot get a lock but appears to not be smart enough realize it won't ever be able to get a lock, and there does not appear to be a working way to disable the poorly though out feature in office any more.

This *BUG* is a mess, and from the number of posts about it I bet is annoying just about all users of office and NFS as the condition required to cause to be a problem is a common condition and once you hit the condition a pain to work around, and there does not appear to be a working way to disable it.

I cannot agree with importance Low...this one is a seriously annoying bug on a poorly though out feature.
Comment 11 Joel Madero 2013-04-22 02:42:45 UTC Comment hidden (obsolete)
Comment 12 Bill B 2015-01-03 01:44:20 UTC
I'd like to add weight to this option- manually removing locks is something I have to do too regularly to be funny. I keep my files on a NAS and there is no security issue as it is generally only me using them- a common situation I would have thought.
Sure, some sort of warning note if it is felt necessary but this really should be under user control/override.
Comment 13 Marcel Partap 2015-01-11 17:40:17 UTC
Opening old files from within an archived file tree messes with the metadata (last modified timestamp) of directories because a temporary lock file is created next to the original file. The current known method (i.e. "best practice") of having to modify the original /usr/bin/libreoffice shell script to uncomment
> # file locking now enabled by default
> SAL_ENABLE_FILE_LOCKING=1
> export SAL_ENABLE_FILE_LOCKING
is a flimsy kludge at best.

With the versatile vim text mode editor, there is a similar issue with its "swap" files - and a perfect solution as well (s/swap file/lock file/):

> " Store swap files in fixed location, not current directory.
> set directory=/var/lib/vim/temp//

> 'directory' 'dir'       string  (default for Amiga: ".,t:",
>                                  for MS-DOS and Win32: ".,$TEMP,c:\tmp,c:\temp"
>                                  for Unix: ".,~/tmp,/var/tmp,/tmp")
>                         global
>         List of directory names for the swap file, separated with commas.
>         - The swap file will be created in the first directory where this is
>           possible.
>         - Empty means that no swap file will be used (recovery is
>           impossible!).
>         - A directory "." means to put the swap file in the same directory as
>           the edited file.  On Unix, a dot is prepended to the file name, so
>           it doesn't show in a directory listing.  On MS-Windows the "hidden"
>           attribute is set and a dot prepended if possible.
>         - For Unix and Win32, if a directory ends in two path separators "//"
>           or "\\", the swap file name will be built from the complete path to
>           the file with all path separators substituted to percent '%' signs.
>           This will ensure file name uniqueness in the preserve directory.
Comment 14 Marcel Partap 2015-01-11 19:26:48 UTC
Created attachment 112097 [details]
/usr/lib/libreoffice/share/registry/disable-file-locking.xcd

Oh my gosh. SAL_ENABLE_FILE_LOCKING doesn't even do what I thought.. lock files would be created anyway.. until I finally managed to force my will upon tah off1ce. shhhshshs^^^
For reference,
> SAL_ENABLE_FILE_LOCKING=0
> unset SAL_ENABLE_FILE_LOCKING
> org.openoffice.Office.Common/Misc/UseDocumentSystemFileLocking = false
> org.openoffice.Office.Common/Misc/UseDocumentOOoLockFile = false
make NO difference. Only
> org.openoffice.Office.Common/Misc/UseLocking = false
turns that ##### off.
Comment 15 Tim Banchi 2015-12-14 17:51:13 UTC
Hello,
thanks, for me it already worked on a webdav share to comment export SAL_ENABLE_FILE_LOCKING in Ubuntu with LO 5.0.3.2

However, we also have a bunch of Windows clients on our webdav-server.

I found Program Files\Libreoffice 5\share\registry and added the file disable-file-locking.xcd there. There is no quickstarter, so soffice.bin is not running. Still the lock file is created when I open a document on a webdav share.

Does anybody have a solution for Windows aswell?

Tim!
Comment 16 Xisco Faulí 2019-06-27 11:53:08 UTC
*** Bug 123862 has been marked as a duplicate of this bug. ***
Comment 17 Mike Kaganski 2019-07-08 02:24:46 UTC
I propose this to be WORKSFORME.

Rationale:
1. The requested functionality is a power user feature, requiring users to have clear understanding of what they do and what are the drawbacks (e.g. possible conflicts on simultaneous edits on filesystems without in-built locking present, or absent information about who has locked the file on another system).
2. Since version 4.2, we have Expert Configuration feature [1] allowing one to set different power-user settings from Options; since version 5.0, the feature allows searching [2], making it easier to search for needed settings. Find the feature on Options->LibreOffice->Advanced->Open Expert Configuration.
3. The requested functionality is already present using 'org.openoffice.Office.Common/Misc/UseLocking' setting (controlling creation of lockfiles and using locking in general), and 'org.openoffice.Office.Common/Misc/UseDocumentOOoLockFile' setting (controlling whether the present lockfile will be considered when deciding if the file is locked by someone else). For curious, the details about effects of the settings are in function SfxMedium::LockOrigFileOnDemand [3].

[1] https://wiki.documentfoundation.org/ReleaseNotes/4.2#GUI
[2] https://wiki.documentfoundation.org/ReleaseNotes/5.0#Expert_Configuration_usability_improvements
[3] https://opengrok.libreoffice.org/xref/core/sfx2/source/doc/docfile.cxx#LockOrigFileOnDemand