<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Can't edit file on samba shares ( see comment 28 )" href="https://bugs.documentfoundation.org/show_bug.cgi?id=115747#c36">Comment # 36</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Can't edit file on samba shares ( see comment 28 )" href="https://bugs.documentfoundation.org/show_bug.cgi?id=115747">bug 115747</a> from <a class="email" href="mailto:jluth@mail.com" title="Justin L <jluth@mail.com>"> Justin L</a> <pre>(In reply to Thorsten Behrens (CIB) from <a href="show_bug.cgi?id=115747#c35">comment #35</a>) > the question is, does setting UseDocumentOOoLockFile > to false constitute a valid workaround? >From a testing perspective, the result is that files can be saved (no warnings, just a save as normal). Opening files result in a warning and read-only mode. (P.S. no "user" will be able to answer questions about what is an acceptable work-around. Now we have at least 3 variables related to locking - how can anyone know what the implications of any of this are, especially when no definitions have been given? Based on <a href="show_bug.cgi?id=115747#c19">comment 19</a>, this is not a "rare" case, so it would be really hard to determine if preventing ANY use of a dotlock file is valid in every case.) It seems like your concern already had been addressed. Wasn't setting UseDocumentSystemLocking = false a good enough workaround for those who want to require the existence of a lock file? (Perhaps not - I'd guess that the benefit of ALSO using a system lock is that the user CANNOT override it, like they CAN do with an OOo lock file. Probably also worth noting is that it isn't checking if the system SUCCEEDED in using it's own locking mechanism, only that it would try...). UseDocumentSystemFileLocking: Allows to specify whether the OOo document file locking mechanics should use the system file locking (default true). UseDocumentOOoLockFile: Allows to specify whether the OOo document file locking mechanics should use the lock file for locking (default true). UseLocking: Allows to specify whether locking should be used at all. Use this setting only for debugging purpose (default true). UseWebDAVFileLocking: Determines if WebDAV-specific file locking is used for documents on WebDAV shares. It is not recommended to set this option to 'false' in scenarios where multi-user, concurrent read/write access to WebDAV share is required (default true). Because A) this is a regression, B) which already had an alternate solution (SystemLocking = false), C) and the description uses the terminology "Allow" instead of "Mandatory", D) involving an unnecessary file for normal operation, E) caused by undocumented rationale for the changed behaviour, I suggest reverting this bit and introducing a MandatoryLocking variable to handle the very unique situations where locking files actually have any value.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>