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.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
*** Bug 54876 has been marked as a duplicate of this bug. ***
(Reopening as there are still requests being made to allow disabling of lock files.)
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
*** Bug 51546 has been marked as a duplicate of this bug. ***
(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.
Sure, with 2 duplicates plus your info I'll bump it up. No promises that it'll get done soon, this is an enhancement request and ultimately a developer will have to like this enough to implement it. Marking as Medium
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.
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.
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.
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!
*** Bug 123862 has been marked as a duplicate of this bug. ***
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