Bug 37575

Not a bug: changed to "enhancement".

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".

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.

[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

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

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

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

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

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 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.

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.

Okay, now NEEDINFO status. (Just someone who test this is needed...)

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?

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 :(

Hi Glenn, please take a look at: Bug 36852, Bug 50276, Bug 65854, Bug 56544

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.

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.

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