[Bug 115747] Can't edit file on samba shares

[Thorsten Behrens]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1032 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20190112/67ca6591/attachment.sig>