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
Attachment:
signature.asc
Description: PGP signature