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

classic Classic list List threaded Threaded
5 messages Options
Thorsten Behrens-6 Thorsten Behrens-6
Reply | Threaded
Open this post in threaded view
|

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

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 <[hidden email]> ---
> (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
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (1K) Download Attachment
Mike Kaganski Mike Kaganski
Reply | Threaded
Open this post in threaded view
|

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

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
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Thorsten Behrens-6 Thorsten Behrens-6
Reply | Threaded
Open this post in threaded view
|

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

Hi Mike,

Kaganski Mike wrote:
> 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:
>
True, but that's a very special corner case, no?

Another corner case, that IIRC was part of the problem which led to
the bugfix under discussion, was a disk / quota full situation.

And a third case was the WebDAV problem, where a server might refuse
LOCK, or only permit it for authorized users.

In general, it's pretty hard for LibreOffice to guess the correct
thing to do, with this plurality of failing to write, or fully write,
a lockfile. So the right thing to do then, IMO, is for it to back off,
and take the only safe path: open the document read-only.

> 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.
>
Then the sensible thing to do is disable lockfiles in those
environments - if both conditions hold true? But that's something only
a local administrator can decide correctly.

> You cannot require that "either all file systems you use support
> lockfiles, or you disable their usage".
>
Well but what else can one do to ensure correct behaviour? If there's
a way to tell a specific filesystem apart from the path name, or OS
query functions, then of course another set of lock disable config can
be added. Problem is, IIRC that was not possible in all cases for
mapped / mounted network drives.

> 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).
>
That appears backwards to me. My take is, software should always go
the safe path by default, and offer the dangerous one only after
explicit consent. So with the infobar idea, that would mean open
read-only, but perhaps provide the option to switch to edit mode while
keeping the filename?

> 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.
>
Well, we always try to also use FS-native locks, so most of the above
cases are covered. But you're right, for those occasions the lockfiles
were invented for (unreliable/incomplete FS locking), that will break
down if e.g. MS Office has the file open, too. For that, the measure
of last resort is looking at the modification date just before saving
(which only helps for one half of that problem, obviously).

But the argument "lock files are not safe 100% of the time, so we
shouldn't insist on writing them" is a non sequitur - unless you then
conclude we should abandon them entirely.

I still maintain the current behaviour is the least worst, avoiding
silent errors in locking shared files (interestingly, the problematic
examples given were all _on network shares_, i.e. exactly the place
where previously locking was subtly faulty). If there's a way to give
local setups more fine-grained control over the LibreOffice locking
subsystem, or if perhaps the user experience can be improved (start of
brainstorming above), I'm eager to hear it!

Cheers,

-- Thorsten
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (1K) Download Attachment
Mike Kaganski Mike Kaganski
Reply | Threaded
Open this post in threaded view
|

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

Hi Thorsten!

On 28.01.2019 5:32, Thorsten Behrens wrote:

> Kaganski Mike wrote:
>> 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).
>>
> That appears backwards to me. My take is, software should always go
> the safe path by default, and offer the dangerous one only after
> explicit consent. So with the infobar idea, that would mean open
> read-only, but perhaps provide the option to switch to edit mode while
> keeping the filename?

Well - that'd be OK IMO :-)

--
Best regards,
Mike Kaganski
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Wols Lists Wols Lists
Reply | Threaded
Open this post in threaded view
|

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

On 28/01/19 07:55, Kaganski Mike wrote:

> Hi Thorsten!
>
> On 28.01.2019 5:32, Thorsten Behrens wrote:
>> Kaganski Mike wrote:
>>> 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).
>>>
>> That appears backwards to me. My take is, software should always go
>> the safe path by default, and offer the dangerous one only after
>> explicit consent. So with the infobar idea, that would mean open
>> read-only, but perhaps provide the option to switch to edit mode while
>> keeping the filename?
>
> Well - that'd be OK IMO :-)
>
Maybe with a follow-up warning on saving "you are about to save a file
someone else may have open. Either you or they could lose their changes".

Cheers,
Wol
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice