Bug 159717 - Lock file warning dialog promotes data disaster
Summary: Lock file warning dialog promotes data disaster
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.5.5.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: File-Lock
  Show dependency treegraph
 
Reported: 2024-02-14 11:26 UTC by Dan.Ka
Modified: 2024-02-19 14:20 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Dialog Window: "Document in Use" (9.85 KB, image/png)
2024-02-14 11:30 UTC, Dan.Ka
Details
Save dialog (35.00 KB, image/png)
2024-02-19 14:20 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dan.Ka 2024-02-14 11:26:49 UTC
Description:
Use Case:
We are using LibreOffice at our office. Our documents reside on a server share that everybody can access. We rely on the lock file mechanism to prevent people from editing the same document at the same time.

Context:
When opening a file, the lock file mechanism allows Libre Office to warn users about a document being already open at another computer. Recently, this dialog has changed and now easily allows to open a document while ignoring the lock file.

Issue:
In my opinion, the “Open” button is just too prominently placed. As one is used to click on “Open” buttons, people tend to use it without much thinking. However, this button overrides the lock file mechanism and as soon as the user who clicked on the “Open” button closes the document, data disaster happened:
a) on saving data, the user who had the lock in the first place will overwrite any changes made by the user who clicked on the “Open” button
b) any other user will be able to open the file without being informed about the document being already open as the lock file has been removed.

Suggestion:
- Allow to remove/disable the “Open” button in this dialog
- Modify the dialog so that “Open” is not that prominent (e.g. that it is smaller or that a warning pops up when clicked)?


Steps to Reproduce:
1) Open a document (on a server share) at PC1
2) Open the same document at PC2. Click "Open" button in the "Document in use" dialog
3) Close the document at PC2.


Actual Results:
The lock has been removed.

Expected Results:
The user should have been instructed by the dialog at step 2) to open the document in read only mode instead.


Reproducible: Always


User Profile Reset: No

Additional Info:
I think this is a UX design issue rather than a technical issue.
Comment 1 Dan.Ka 2024-02-14 11:27:12 UTC
See also this forum post:

https://ask.libreoffice.org/t/new-lock-file-dialog-promotes-data-disaster/102097
Comment 2 Dan.Ka 2024-02-14 11:29:02 UTC
Official documentation about lock file:
https://wiki.documentfoundation.org/Videos/Preventing_data_disaster#Lock_file
Comment 3 Dan.Ka 2024-02-14 11:30:57 UTC
Created attachment 192559 [details]
Dialog Window: "Document in Use"
Comment 4 Dan.Ka 2024-02-14 11:33:46 UTC
Comparison between new style (on the left) and old style (on the right) "Document in Use" dialog:

https://bug-attachments.documentfoundation.org/attachment.cgi?id=180851


From bug 141026
Comment 5 Mike Kaganski 2024-02-14 12:25:03 UTC
Note that since commit 2b4cd99d3360ccffb9829a02412824864d045753, overwriting files is possible on Windows (which is obviously used by OP). On other platforms, it was also possible before that.
Comment 6 Dan.Ka 2024-02-14 13:39:31 UTC
(In reply to Mike Kaganski from comment #5)
> Note that since commit 2b4cd99d3360ccffb9829a02412824864d045753, overwriting
> files is possible on Windows (which is obviously used by OP). On other
> platforms, it was also possible before that.

Hi Mike,
Sorry, I don't understand how your comment pertains to my bug report. A "document locking mechanism" should prevent users from overwriting or even editing documents that are already open in another instance of libre office - independent of the feature of the OS and FS. I was under the impression that the current locking mechanism is indeed OS and FS agnostic.
Comment 7 Mike Kaganski 2024-02-14 13:45:04 UTC
(In reply to Dan.Ka from comment #6)
> Sorry, I don't understand how your comment pertains to my bug report.

It helps others (I asked UX team to take a look at it) to see the increased severity on the major platform where it's used. Before that change, even without the lockfile, the filesystem-level file locking would prevent from "data disaster" (just because you couldn't open the file in read-write mode, and couldn't overwrite a file already opened by another person for writing). Now the change I mentioned, together with the issue you are pointing to, allow such an overwrite.
Comment 8 Heiko Tietze 2024-02-15 09:56:37 UTC
Take a look at the attachments of bug 141026, it was always possible to open locked files. 

The data loss actually happens only after someone else saved first, and you ignore the warning. We could disallow overwriting files with a newer timestamp.

And of course we could drop the ability to open such a file in first place.
Comment 9 Mike Kaganski 2024-02-15 10:14:18 UTC
(In reply to Heiko Tietze from comment #8)
> Take a look at the attachments of bug 141026, it was always possible to open
> locked files. 

Heh, it was tdf#108210 that I fixed in 2018 (in version 6.1). Before that, it was *impossible*.
Comment 10 Mike Kaganski 2024-02-15 10:19:28 UTC
(In reply to Heiko Tietze from comment #8)
> Take a look at the attachments of bug 141026

Additionally, you seem to ignore my explicit words in comment 5, that on Windows, it was different compared to Linux, where there was never a functional filesystem locking. So showing an image on Ubuntu is pointless, when the user is on Windows (indeed, OP had not indicated their OS). On Windows, my solution mentioned above used to check the filesystem locking, and didn't offer the "Open" button at all, when there was an active filesystem locking.
Comment 11 Heiko Tietze 2024-02-15 10:25:34 UTC
(In reply to Mike Kaganski from comment #10)
> fixed in 2018
That's almost "always possible" ;-)

Back to the topic: What do you think about the two ideas: a) don't allow overwriting of files with different timestamp, or b) don't open locked files.
Comment 12 Mike Kaganski 2024-02-15 10:32:03 UTC
(In reply to Heiko Tietze from comment #11)
> ideas: a) don't allow overwriting of files with different timestamp
Maybe. Keep the timestamp at the time of opening, and at least warn when saving and the timestamp is different ... Looks reasonable.

> b) don't open locked files
Please read tdf#108210 that I mentioned.
Comment 13 Heiko Tietze 2024-02-19 14:20:05 UTC
Created attachment 192637 [details]
Save dialog

The expert option AllowOverrideLocking toggles whether you can open a file anyway, does not work here for some reason (always disabled). The implementation is quite weird with

uui/source/iahndl-locking.cxx
bool bAllowOverride = xRetry.is() && officecfg::Office::Common::Misc::AllowOverrideLocking::get();
...
vcl::OpenLockedQueryBox aDialog(pParent, aHiddenData, bAllowOverride);
...
if (!(bEnableOverride && officecfg::Office::Common::Misc::AllowOverrideLocking::get()))

If we change the behavior it should rather be the save dialog, and I suggest to prevent overwriting by asking for a different filename.