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)
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
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
I can reproduce this problem using Ubuntu 14.04 LTS and Libreoffice 4.4 and 4.5-dev under one condition which Michael Meeks already suspected: I have to open the document using a smb:// url. If i use the local gvfs mount (/run/user/1000/gvfs/smb-share...) it works. Windows also works on smb.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.0) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-02-21
I guess this bug is a duplicate of bug 56544 which is solved for versions ≥ 5.0.6, ≥ 5.1.1 and master. Closing as duplicate. Please, feel free to reopen if this bug is not fixed for you with a recent dev. version. Best regards. JBF *** This bug has been marked as a duplicate of bug 56544 ***