Date: prev next · Thread: first prev next last
2019 Archives by date, by thread · List index


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


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.