Summary: | Lock file warning dialog promotes data disaster | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Dan.Ka <bugs.documentfoundation.org> |
Component: | LibreOffice | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEW --- | ||
Severity: | normal | CC: | heiko.tietze |
Priority: | medium | ||
Version: | 7.5.5.2 release | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=157943 https://bugs.documentfoundation.org/show_bug.cgi?id=141026 |
||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 114300 | ||
Attachments: |
Dialog Window: "Document in Use"
Save dialog |
Description
Dan.Ka
2024-02-14 11:26:49 UTC
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.
|