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.
See also this forum post: https://ask.libreoffice.org/t/new-lock-file-dialog-promotes-data-disaster/102097
Official documentation about lock file: https://wiki.documentfoundation.org/Videos/Preventing_data_disaster#Lock_file
Created attachment 192559 [details] Dialog Window: "Document in Use"
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
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.
(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.
(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.
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.
(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*.
(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.
(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.
(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.
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.