Bug 37575

Summary: Files are not locked on File Open but only when the user requests a save
Product: LibreOffice Reporter: Glenn Sommer <gsommer>
Component: LibreofficeAssignee: Not Assigned <libreoffice-bugs>
Status: NEEDINFO --- QA Contact:
Severity: normal    
Priority: medium CC: cno, jbfaure, jmadero.dev, qubit, reisi007
Version: 3.3.2 release   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Glenn Sommer 2011-05-25 04:29:01 UTC
The old behaviour of OpenOffice (>3.1) was to get full lock on filen on open.

The current behaviour of both OpenOffice and LibreOffice is to NOT get full lock on file, until the user clicks "Save".

This is inconvenient in multi-user environments, as two users might be editing the same file - without knowing someone else it editing too.


The current scenario is:

* User A opens file: "sharedfile.odt"
* User A edits several lines in the file, but does NOT click save yet!
* User B opens the same file - and starts to edit. (NOTE: as user A DID NOT click save yet - no warnings are displayed).
* User B saves the work, and closes down.
* User A tried to save the work - but is warned about the file has changed since open.
User A now has to save it in another file, and manually merge the correct changes. (Not very user-friendly - and even worse, the user gets an option to override, which will lead to data-loss)


The old (and preferred) behaviour:
* User A opens file: "sharedfile.odt"
* User A edits several lines in the file, but does NOT click save yet!
* User B tries to open the file - but is warned about user A already has the file open (In this case, User B can open the file read-only, and at-least watch the content)
The old strategy ensures there's no data-loss, and the user is always warned if others are accessing the same shared file.
  

It's worth to mention, the Windows version of LibreOffice still used the old and preferred behaviour!
The Linux version does not.

This is tested on a local filesystem and on NFS and Samba shares (Both with and without filesystem locking)


workaround:
Edit the soffice startup-script to look for the .~lock# file, and manually force LibreOffice to open read-only. 

(NOTE: Even-though LibreOffice uses filesystem-locking, the .~lock# file is still created!)


Suggested fix:
Go back to the old behaviour of getting exclusive lock on the file on open (Not just on save)
Comment 1 Jean-Baptiste Faure 2011-05-29 09:58:14 UTC
Not a bug: changed to "enhancement".
Comment 2 Glenn Sommer 2011-05-29 23:44:55 UTC
Not a bug?
It's an important regression since 3.1.

In multiuser-environments this is a highly important change - which makes LibreOffice unsuitable for any company that uses shared files!
The fact it - it USED to work, and now it does not.

Any company wanting to use LibreOffice is stuck with 3.1 due to this bug! (Any company with shared files that is)

Worst-case is data-loss - which in my eyes classifies as a "major".
Comment 3 Jo Neumann 2011-07-15 04:54:55 UTC
I agree with Glenn. It took us 1h to finally realise that this is intended behaviour. But it is really unexpected. A user can open an already opened document without warning. So there is no way for him to know, if he now is the privileged user. The change of behaviour after the document is saved makes it even more confusing. So for now our workaround is to 

1) open the document,
2) make some little change and save,
3) work as usual.

In my opinion the old behaviour is much more usable. If someone wants to just read the document without altering it, he should get a message to confirm and then continue in read-only mode. But the user needs to be sure which privileges he has and what behaviour he can expect. This is not the case in the current behaviour because he might save changes, which are later overwritten by some other user who just discards the warning message. The latter one can alter the document but only gets the warning when he has finished.
Comment 4 Björn Michaelsen 2011-12-23 12:03:01 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 5 Florian Reisinger 2012-08-14 13:58:10 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 6 Florian Reisinger 2012-08-14 13:59:28 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 7 Florian Reisinger 2012-08-14 14:04:03 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 8 Florian Reisinger 2012-08-14 14:06:16 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 9 Glenn Sommer 2012-08-15 07:44:00 UTC
There has been no request for additional information - I have NO IDEA why this bug was marked as "NEEDINFO"

This bug is still valid, and a major regression since 3.1.
This bug still prevents companies to use LibreOffice in a multi-user environment.
Comment 10 Michael Meeks 2012-08-15 10:05:51 UTC
comment 4 was surely such a request ? we rely on users to re-test issues for new releases.

However in this case it sounds like this was deliberate.

Much as I loathe specifications for trivial changes, the file load/save/locking situation is sufficiently, horribly tangled - and riddled with nasty problems (like missing samba locking under Linux) that this is a minefield.

I guess if you want a full fix here, first we need to know what that looks like - which means working with UX to iterate & improve a specification for this.

It is worth noticing that only old gnome-vfs' on some Linux's had built-in smb:// locking support; new gio backends do not (IIRC), if you're using a native platform mount the situation is different again - so if this works on windows as you expect; I imagine there is simple some missing implementation of locking in the underlying implementation.

It'd be good to know what linux, and how the SMB mount / access is done.
Comment 11 Glenn Sommer 2012-08-15 14:17:02 UTC
Under Windows LibreOffice works as expected - both locally and under Samba shares.

Under Linux, LibreOffice does not work as expected*. (Mounted or not mounted does not make any difference).

Please note, this is _NOT_ an issue about locking a file, it's an issue regarding WHEN the file is locked!
As I wrote in my initial comment #1, the behavior changed since version 3.1, thus making LibreOffice unusable for multi-user environments.


* Expected:
Have filelocking working as it is under Windows - and as it worked before version 3.1. Please see comment #1 for reference.
Comment 12 Florian Reisinger 2012-08-15 14:57:20 UTC
Okay, now NEEDINFO status. (Just someone who test this is needed...)
Comment 13 Zsolt Szokolai 2012-11-05 18:36:57 UTC
I agree with Glenn. The locking is important in a multi user environment. I wrote my experience in report #56544. Is there an option which can force the creating the .~lock... file?
Comment 14 Glenn Sommer 2012-12-10 12:22:54 UTC
I can confirm this issue is still present in LibreOffice 3.6.2.2.

Using lsof, it's clear that when a file is open using LibreOffice - there is no lock on the file (it's open with read/write access - but NO locks!).
When the file is written to (during saving procedure), the file keeps the write-lock on the file.

This major regression is still keeping companies away from using LibreOffice in a multiuser environment.
We're still stuck with version 3.0 till this issue is fixed :(
Comment 15 ign_christian 2013-07-11 05:36:53 UTC
Hi Glenn, please take a look at: Bug 36852, Bug 50276, Bug 65854, Bug 56544
Comment 16 Glenn Sommer 2013-08-02 10:24:04 UTC
I can confirm, this regression is still in LibreOffice 4.0.2.
LibreOffice still does not set exclusive lock when opening documents. (It is still waiting with the exclusive lock till the user requiest a save).

LibreOffice above 3.0 is still not useable in multi-user environments. (Unless you patch the product yourself, with your own file-locking code)

For my company, I've worked around this issue by patching the start-up script launching LibreOffice, to react on file-lockings. This is not ideal - but, it's currently the only option we have, if we need to use LibreOffice >3.0.

ign_christian: I've look at those bug-reports. They have a similar pattern, but - it's still not quite the same.
This bug-report is for the major regression introduced in the 3.1 series. Where file-locking was moved from the "open method" to the "save method" - and thereby making LibreOffice unfitted for multi-user environments.
Comment 17 Joel Madero 2014-11-04 03:35:54 UTC
Moving to UNCONFIRMED as this was never confirmed by QA. Also - please don't change the severity/priority on your pet bugs, it doesn't help anyone.
Comment 18 Robinson Tryon (qubit) 2014-12-27 18:02:32 UTC
TESTING on Ubuntu 14.04 + LO 4.4.0.1

(In reply to Glenn Sommer from comment #11)
> Under Linux, LibreOffice does not work as expected*. (Mounted or not mounted
> does not make any difference).

REPRO steps:
1) Open a new document in Writer, type 'hello, world' and save as 'sharedfile.odt' in /tmp
2) chmod 666 /tmp/sharedfile.odt
3) Quit LibreOffice

> * User A opens file: "sharedfile.odt"

Or basically:
4) Open the saved 'sharedfile.odt' in LibreOffice

> * User A edits several lines in the file, but does NOT click save yet!

Add a new line "Walrus walrus"

> * User B opens the same file - and starts to edit. (NOTE: as user A DID NOT
> click save yet - no warnings are displayed).

NOREPRO: When I tried to open the file as the 2nd user, I got a warning about the file being locked for editing by the 1st user.

I also tried using 2 parallel installs instead of 2 users (each installwith a different UserProfile directory). I then get the warning:

  Document file 'hello.world.odt' is locked for editing by yourself
  on a different system since 27.12.2014 12:38

  Open document read-only, or ignore own file locking and open the
  document for editing.

> This is tested on a local filesystem and on NFS and Samba shares (Both with
> and without filesystem locking)

I can't reproduce this problem on the local filesystem. Please test again with modern versions of LibreOffice (e.g. 4.3.5 or later) and make sure to provide steps for reproducing the problem. Thanks!

Status -> NEEDINFO

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.