Summary: | Control File Locking from Options | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | sqrtyl |
Component: | Libreoffice | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | medium | CC: | andrzej, courrier.oou.fr.mjk, enda_k2, gellert.gyuris, jmadero.dev, mpartap, nofunnynameavailable, rahhorizon |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | /usr/lib/libreoffice/share/registry/disable-file-locking.xcd |
Description
sqrtyl
2011-10-04 04:06:47 UTC
[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 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 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 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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.