Hi Justin, Xisco, moving this discussion to the dev list (wider audience, and we can bikeshed as much as we like about technicalities w/o bothering end users). Context:
https://bugs.documentfoundation.org/show_bug.cgi?id=115747
I'd consider the below worth fixing:
--- Comment #36 from Justin L <jluth@mail.com> --- (In reply to Thorsten Behrens (CIB) from comment #35)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.
My expectation would be that UseDocumentOOoLockFile=false does not create those lockfiles, and therefore opens a file read-write. That's a bug in my view. Moderate re-order for clarity:
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? ... 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).
Yeah, filing locking is a known mess. Essentially _any_ change there will unearth odd quirks & corner cases. See below for an attempt to better define semantics.
Based on comment 19, 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.)
I somehow failed to find more examples on Ask, Xisco: do you recall other cases?
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.
As always, one person's regression is another person's bugfix. Those OOo lockfiles have a rather long-winded history, and were introduced because especially on network shares, cross-platform system file locking never quite worked. Since the change is shipped in versions for almost a year, instead of a revert I'd much prefer we take the occasion and better define requirements and semantics for file locking. From my memory: - until 2008, there was just system file locking, which led to problems in preventing overwrites on documents accessed from different platforms. https://bz.apache.org/ooo/show_bug.cgi?id=85794 has quite some details, and a specification document - that change of course led to bugs, starting with: * https://bz.apache.org/ooo/show_bug.cgi?id=95809 (bring back system file locking) * https://bz.apache.org/ooo/show_bug.cgi?id=100123 (actually lockfiles _also_ break workflows, so add an option) * https://bz.apache.org/ooo/show_bug.cgi?id=102931 (cop-out, there's apparently still corner-cases left where _no_ locking happens) - then proper locking on WebDAV shares was implemented via tdf#82744 * which inevitably led to problems when a user couldn't write * so UseWebDAVFileLocking was added to disable it (please amend the history, especially if StarOffice old hands remember additional details) Taking this all together, my mental model of the LibreOffice document file locking requirements is: * when opening read-write, make sure the file is locked (via a number of configurable means). Failing to take _any_ of those locks should lead to read-only opening. * by default, use as many lock-signalling (system APIs plus lock files) as possible, so other programs have a chance to detect the access, too * as a safety measure, when saving, check if the document access time has changed, and warn the user that potentially someone else accessed the document For corner cases or historical setups that cannot accomodate change, configuration options have been introduced (and I wouldn't object continuing down that path). Makes sense thus far? Cheers, -- Thorsten
Attachment:
signature.asc
Description: PGP signature