If there are two users in the system, one edits a file, but doesn't exit cleanly and the lock file remains, trying to open it with a different user shows the usual dialog, but with the following possible actions (normally the middle option is "Open", and the text is slightly different, in this case it includes the other user's name): "Open Read-Only", "Open Copy", "Cancel". Basically LO still thinks the file is open by a different user. The easiest way to repro is to: - save a lock file while the file is open, - edit it with a text editor manually by replacing the user name in the first field with a different one (it's in ",Computer/User," form), - place it next to the original file when the file is not opened, and open it again. Another way (tested in Windows 7): - create a different user in the system, set a password for it, - start LO with that user by shift-right-clicking soffice.exe and selecting Run as different user, - open a file, - kill LO in task manager, - start LO with the first user, and try to open the same file again. Reproduced with 5.3.3.2 & 3.3.0 / Windows 7. Not sure whether it affects Linux, it likely does, but I haven't checked.
Repro. Arch Linux 64-bit, KDE Plasma 5 Version: 5.5.0.0.alpha0+ Build ID: c855400e9686ddd8bcba5691393f839f6f52c966 CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on June 2nd 2017
Elaborating on the dialog and choices: 1. If there's a lock file, and the same user tries to access the file from the same LO path: file is opened without confirmation dialog. 2. If there's a lock file, and the same user tries to access the file from a different LO path: there is a dialog with text STR_ALREADYOPEN_MSG from [1], choices are "Open Read-Only", "Open", "Cancel". 3. If there's a lock file, and a different user tries to access the file: there is a dialog with text STR_LOCKFAILED_MSG from [1], choices are "Open Read-Only", "Open Copy", "Cancel". An idea I had is to only check system lock if that's what the code relies on with that file system. I discussed with Mike, one concern is that we can't really know for sure if the system lock is reliable underneath. His conclusion was that first the code should check if the file can be opened for writing, and then in the dialog allow the user the choice to open the file. So the dialog shouldn't be completely eliminated. In this case an extra text is needed, because the current ones don't cover this option (they mention situation and choices). [1] https://opengrok.libreoffice.org/xref/core/uui/inc/strings.hrc
(In reply to Aron Budea from comment #2) > 3. If there's a lock file, and a different user tries to access the file: > there is a dialog with text STR_LOCKFAILED_MSG from [1], choices are "Open > Read-Only", "Open Copy", "Cancel". I pasted the wrong id, the correct text for this is STR_OPENLOCKED_MSG.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2a7057250c8f73fdfb4c65a7525d17e9770459df tdf#108210: Allow to ignore a lock file if there's no filesystem lock It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 115426 has been marked as a duplicate of this bug. ***