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

[Kaganski Mike]

On 12.01.2019 13:28, Thorsten Behrens wrote:
> Context:
>> https://bugs.documentfoundation.org/show_bug.cgi?id=115747
> 
>> 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).

My opinion is that only existing locks may be a reason to open files 
read-only. If you can't write lockfiles, it's not a reason to limit 
one's ability to edit files. That can lead to the problems that 
lockfiles were meant to workaround, but if a specific shared (!) 
filesystem has some special properties that it (1) has no good FS 
locking; and (2) blocks writing lockfiles, then no measures will 
mitigate the problem:

- if users are forced to disable use of lockfiles in LO, this doesn't 
fix the problem anyway - they are just subject to those problems;

- if administrators could change the FS properties so that lockfiles are 
permitted, they should do that anyway when they allow users work on 
shares without reliable FS locking.

But it happens that a user has to work in a directory where they are not 
allowed to create new files at all (directory-level permissions), but 
are allowed to edit a specific file (file-level permissions).

Not all shared filesystems have unreliable FS locking; I had no problems 
with FS-level locking when administered a Windows domain.

Users work in heterogeneous environments; they open files locally (in 
different locations with different permission sets); on USB sticks; on 
network shares with different protocols; on the web; ... whatever a 
tomorrow OS would offer. On one filesystem, lockfiles might be great to 
know who opened your file; on another, they might be prohibited, because 
you as a subcontractor work for someone who gave you a limited access to 
their storage. You cannot require that "either all file systems you use 
support lockfiles, or you disable their usage".

My vision of this would me that if inability to create lockfiles needs 
to be handled specially at all, then at maximum a warning infobar 
telling that "no lockfile was created, so clashes are possible" could be 
shown, but not limiting user's ability to work (because technically 
nothing prevents users).

Anyway, we cannot treat our lockfiles as an ultimate guard, simply 
because LibreOffice only works with files also openable using many other 
applications (ODF is an ISO standard, you remember, and if we can open 
other formats, others can, too). And those other applications ignore our 
lockfiles. So the lockfiles are there to help, not to stay on one's way.

-- 
Best regards,
Mike Kaganski