Bug 120829 - Lockfiles can be overridden
Summary: Lockfiles can be overridden
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: File-Lock
  Show dependency treegraph
 
Reported: 2018-10-23 11:20 UTC by Nigel Arnot
Modified: 2024-01-29 12:20 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Locked dialog (23.43 KB, image/png)
2019-02-18 17:05 UTC, Samuel Mehrbrodt (allotropia)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nigel Arnot 2018-10-23 11:20:30 UTC
Description:
When a Libreoffice document is open by a user A on a shared folder and user B tries to open it, he receives a warning that the file is in use. However, it also says something like "Alternatively, you can ignore the lock file and open the document anyway".

Which is what a non-technical user will choose without thinking, and should almost never do. At the very least, the warning should be far more strongly worded. Maybe "Alternatively, as a last resort, and if your system's management agrees, you can ...", and paint the button red, and insert a final "Are you really sure?" screen.

Better still, make read-only the only option, but I appreciate other users in other places might disagree (until they end up in a fight over whose hours of work have to be re-done). 

It would also be helpful if all the information in the lockfile were relayed to the user attempting the second open. "$file is open for editing by $user on system $hostname and was opened at $time", because the correct work-around involves finding $user and asking him to save and close the file.

I've selected OS = Linux(All). I can't verify whether this behaviour also happens with Windows and Windows servers. Also can't say whether it's always been possible to override lockfiles, or not.

Steps to Reproduce:
1. User A on one system opens a file on a shared-for-write folder
2. User B on a second system attempts to open the same file
3.

Actual Results:
Mildly-worded warning screen that "invites" a non-technical user to commit a great mischief

Expected Results:
Inability for non-technical user to open the file, or a strongly-worded warning screen that makes a non-technical user understand that ignoring a lock file is normally a REALLY BAD IDEA


Reproducible: Always


User Profile Reset: No



Additional Info:
This is an enhancement suggestion follow-up from bug 119381, which is fixed.
Comment 1 Xisco Faulí 2019-01-22 16:20:31 UTC
Reproduced in

Version: 6.3.0.0.alpha0+
Build ID: 392729c735bb82eecf29bae5527ec786ca293f34
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc:
Comment 2 Samuel Mehrbrodt (allotropia) 2019-02-18 17:05:26 UTC
Let UX have a look if wording can be improved.
Comment 3 Samuel Mehrbrodt (allotropia) 2019-02-18 17:05:45 UTC
Created attachment 149381 [details]
Locked dialog
Comment 4 Samuel Mehrbrodt (allotropia) 2019-02-18 17:08:21 UTC
Maybe just show "Open read-only" and "Cancel" buttons by default.

Then have a checkbox "I want to override the lockfile" which changes the "Open read-only" button to an "Open" button.
Comment 5 Heiko Tietze 2019-02-19 07:24:52 UTC
Overriding the lock file should be done only when the previous process has not ended gracefully, right? Don't think we want to take over the work from other users- in this case we open readonly or as a copy.

Open readonly in local mode shows an infobar where the user can enable the edit mode. When opened as a copy (aka inserted from file) it shows the save dialog on ordinary save actions. Sounds like the usual way for me. 

Rather than renaming a message that nobody care about we should tweak the workflow. The (technical) question remains how to deal with the lockfile from a terminated process. Can you evaluate this status safely anyway?
Comment 6 Samuel Mehrbrodt (allotropia) 2019-02-19 07:30:54 UTC
(In reply to Heiko Tietze from comment #5)
> Overriding the lock file should be done only when the previous process has
> not ended gracefully, right? Don't think we want to take over the work from
> other users- in this case we open readonly or as a copy.

No, please read comment 0, especially:

> When a Libreoffice document is open by a user A on a shared folder and user B tries to open it, he receives a warning that the file is in use. However, it also says something like "Alternatively, you can ignore the lock file and open the document anyway".
Comment 7 Samuel Mehrbrodt (allotropia) 2019-02-19 07:32:07 UTC
It can also happen that the lockfile from another user doesn't get cleaned up, so removing the option to open the file (despite locked by another user) is no option.
Comment 8 Cor Nouws 2019-03-06 19:25:38 UTC
from the UX-meeting 2019-03-05:

Dialog + message needs to be discussed
  + "Opening editable potentially ends up in data loss when more users 
    access the same file."
  + checkbox "[ ] Open editable anyway"
  + buttons [Open]   [Cancel] (no "Open read only")

Opinions?
Comment 9 Thomas Lendo 2019-03-14 05:47:54 UTC
(In reply to Cor Nouws from comment #8)
I don't think this is an improvement for the end user.

As there is the infobar when opening read-only, the user is informed. Is the current situation a problem, that is discussed in ask.libreoffice or elsewhere?
Comment 10 Heiko Tietze 2019-03-14 13:23:00 UTC
There is no infobar yet, but it would be consistent. If that's not possible without too much effort the proposal from comment 8 is fine.
Comment 11 Samuel Mehrbrodt (allotropia) 2024-01-29 12:20:41 UTC
The dialog has been reworked since this bug was opened and looks much better nowadays.
Also, there is the option /org.openoffice.Office.Common/Misc/AllowOverrideLocking
which can be used to disable the "Open" button.

So I'd say this bug is sufficiently fixed.