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

[Thorsten Behrens]

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
-------------- 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/20190128/4e6ebd8f/attachment.sig>