Issue 91015 - data loss using concurently OOo3 and another editor in the same network
Summary: data loss using concurently OOo3 and another editor in the same network
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 3.0 Beta
Hardware: All All
: P3 Trivial with 16 votes (vote)
Target Milestone: OOo 3.1
Assignee: mikhail.voytenko
QA Contact: issues@framework
: 95060 95608 (view as issue list)
Depends on:
Reported: 2008-06-24 13:03 UTC by clutz
Modified: 2009-03-10 09:41 UTC (History)
16 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description clutz 2008-06-24 13:03:25 UTC
I tested the filelocking implementation of OOo3 (300m2 Rev 9301) on Windows and
found the following scenarios which lead to data loss:

No File locking for doc-files shared via samba-share:
1) Open a .doc-file that is hosted on a samba-share on Windows-host A
2) Open the same .doc-file on Windows-host B --> file opens editable (!!!BUG!!!)
3) edit the document on host A, save and close the document
4) edit the document on host B, save and close the document

result: changes done in 3) are lost! The file-locking for .doc-Files on windows
is broken.

Another issue affects the file-locking in a heterogenous environment with a file
shared via samba-share, opened in OOo3 on Windows and in OOo2 on linux with
cifs-mount (the bug is reproducible with .doc AND .odt-files):
1) Open a .odt/.doc-file on a Windows host A with OOo3
2) Open the same .odt/.doc-file on a linux-client B with OOo2 --> file opens
editable (!!!BUG!!!)
3) edit the document on host A and B and save the document.

result: the last save-actions wins, the changes of the first save-action are lost.

We currently migrate a lot of our PCs from MSO to OOo. In this time there are a
lot of (alien) documents and templates that have to be shared within both
office-suites.  Besides the OOo-migration, we also introduce linux on an
increasing amount of hosts, so we will have a completely heterogenous
environment with a mix of MSO, OOo2, OOo3, Windows, Linux, Samba-Shares in which
data loss will occur regulary with the current implementation. As the same
scenarios do not cause data loss with the old implementation of OOo2, I think we
cannot introduce OOo3 until this issue is fixed.

Thank you very much for the great work with the new file locking with the
temporary lock-file which seems to be very promising and might solve a lot of
our most important issues, but I think the following adjustments have to be done:

a) file-locking for alien-formats:
The best handling for MSO-formats would be to use temporary lock-files
compatible with the lock-files that MSO use. If this cannot be implemented due
to some reason I think the next best alternative would be to reactivate the old
OOo2 implementation for these kinds of files.

b) compatibility with old OOo2-file locking is required:
That means that all kind of files that are opened with OOo3 must be locked in a
 system-level way that OOo2 also recognizes and denies to open the file
editable. Due to the weakness of OOo2 in that situation also a "select filter"
or an "I/O-Error" message would be correct as long as OOo2 denies the editable

Please add these two scenarios to your testcase and ensure that there is no way
to lose data using OOo3.
Comment 1 mikhail.voytenko 2008-06-24 13:29:10 UTC
The adjustment regarding locking of alien files using the new approach is
possible, at least from the development point of view.

Locking of the file so that OOo2.x recognizes the lock is not acceptable, since
the main reason for the new file locking was getting rid of system file locking.
The system file locking does not work as expected in some heterogeneous
networks. Using the system locking in those networks might let the file stay
locked after document closing.
Comment 2 mikhail.voytenko 2008-10-08 11:42:27 UTC
Ok, so we are going to use the same file locking for the alien documents as
well. Please remember that only OOo3.0 and later versions will recognize that
the file is locked.

Additionally, OOo can try to check whether the file was changed since it is
opened and show a warning in this case. The later scenario is for OOo3.1 since
it needs a UI change, but the locking mechanics for alien documents can be
implemented even in OOo3.0.1 from my point of view. So I set the target to
OOo3.0.1 for now.
Comment 3 oc 2008-10-21 16:00:38 UTC
*** Issue 95060 has been marked as a duplicate of this issue. ***
Comment 4 ilardone 2008-10-22 16:59:36 UTC
Hi: I´m not an expert, but after seeing this problem I think that the issue 
begins when an MSO file is open. In this moment that file is not set as "read 
only" for other users. I became to this conclution when I check that if I open a 
file with OO3 and then I try to open the same file with OO2.4 or MSO aplication 
niether of them detect the "read only" mark.
What I am trying to say is that the problem isn´t when the file is opened by the 
second user. Otherwise, the problem apears at the very first action, when the 
file is openned by the first user.
I hope for a soon solution to this issue, I had to re-install OO2.4 in my 

Comment 5 jordanfey 2008-10-27 18:06:40 UTC
This is a major issue to our company, I've uninstalled the 2 trial versions but 
not having the ability to open .docx files in Open Office 2 is also a nightmare!
Comment 6 billrobo 2008-10-28 01:29:08 UTC
Hi, our company can't afford the the potential for widespread data loss this bug
would cause.  This issue is thus a complete show-stopper for any OOo3
implementation for us (a shame as apart from this OO3 would have been a great
release which we were VERY excited about).

It has caused our company to abandon a company wide OOo3 upgrade indefinitely
and reassign the project team we had assembled.  We are now in the process of
rolling back to OOo2 on our pilot machines.

From our point of view, this is a P1 or P2 issue - what is the escalation process?
Comment 7 mikhail.voytenko 2008-10-28 09:57:49 UTC
I have submitted a new issue 95528 to let OOo use the new file lock mechanics
for alien files as well.

Additionally I have submitted a new issue 95530 to let OOo try to detect on
saving whether the file was changed by another application in between and to
show a warning in this case.

I am closing the bug a "will not be fixed", since it requires support for system
file locking. It was an intension to get rig of system file locking to
workaround the locking-problems in heterogeneous networks. The price for this is
that other applications do not recognize the locking of OOo. The two new opened
issues look to be maximal compromise we can accept in the current circumstances.
Comment 8 mikhail.voytenko 2008-10-28 10:01:15 UTC
Comment 9 billrobo 2008-10-29 01:24:45 UTC
Is there any possibility of having this issue re-opened as it is significant
enough to effect the viability of OOo3 (and potentially OOo) in our business.

We have serious user concerns about wasting time if many hours of work is lost
through simultaneous file editing.  OOo has been our company standard since
version 1.1 and IS currently installed on every desktop, but it is just not
possible for us to exclusively use OOo (eg our Finance team still have a
requirement for Excel).

We always expect to operate in a mixed application environment and our
applications must "play nicely" with each other to be viable - application
interoperability is more than just reading each others files.
Comment 10 mikhail.voytenko 2008-10-29 09:39:34 UTC
The only way to request the old behavior ( system file locking usage ) is to
submit a new feature request to the feature committee.
Comment 11 kendy 2008-10-31 10:09:40 UTC
"The system file locking does not work as expected in some heterogeneous
networks. Using the system locking in those networks might let the file stay
locked after document closing."

mav: Can you please give us the exact example where (in what network type/in 
what consequenses) does it happen?  Eg. with the WebDAV locking 
implementation, there was the same issue; there I solved it so that the lock 
is not set to infinity, but to 3 minutes, and OOo (while the document is open) 
sends renewal lock requests 30 seconds before the expiration.  If OOo crashes, 
or if network outage happens, the lock expires on the server.  Maybe the same 
would be possible here...
Comment 12 Stefan Weigel 2008-11-02 20:40:39 UTC
*** Issue 95608 has been marked as a duplicate of this issue. ***
Comment 13 billrobo 2008-11-03 04:39:18 UTC
What is the process required to submit a feature request to the features committee?


1/ Its disappointing to have to raise a feature request to fix (what is for us
at least) a significant bug with major data integrity issues.

2/ Also disappointing that major issues may be so lightly dismissed.  It gives
the unfortunate appearance of shutting down dissent.
Comment 14 aladdin2k7 2008-11-03 08:51:15 UTC
I confirmed.
Comment 15 mikhail.voytenko 2008-11-03 10:16:15 UTC
mav->kendy: The temporary locking looks to be a server feature of the Webdav
protocol. At least I do not know about such a possibility in local filesystem
locking implementation.

mav->hro: Could you please post the issues referring to the heterogeneous file
locking scenario problems in OOo2.x. 

mav->billrobo: If the issue was dismissed, we would not discuss it further. The
issue status is changed to explicitly point that the bug will not be fixed, at
least as a bug. Absence of file system locking is part of the current file
locking feature, and that could be changed only by feature change. 

As for the feature request, I would suggest to leave this issue as it is and
open a new feature issue, that would explicitly request file system locking
usage. It would be a consistent result of this issue: two bugs that can be
fixed, and one feature request from users who are not satisfied with the
limitations caused by the current locking feature implementation. The new
feature issue can be sent to me as well.
Comment 16 camillem 2008-11-03 10:50:49 UTC
@mav : IMHO, it can't be considered as something else than a bug, by any
standard. Data loss can't be the desired behavior of the application. So, when
an application doesn't have the intended behavior, it's a defect. 
I think the different sides of this issue have to be addressed all together :
splitting it into different issues is quite confusing, at least for me.

We need a file locking system that covers all the different scenarios, which
boil down to:

-The file is open and not shared by user A : then user B can only open it in
read-only mode.
-The file is open and sharded by user A : 
-- If user B'application can understand the sharing mecanism, then the file
opens in shared mode
-- If user B'application can not understand the sharing mecanism, then the file
is open in read-only mode 

And of course, this should work whatever the file type is.

Comment 17 eclypse 2008-11-03 15:00:45 UTC
Issue 95528 (for an enhancement request) appears to be what we're trying to go
after to resolve this, has anyone else looked at this issue?
Comment 18 mhatheoo 2008-11-03 15:03:50 UTC
==> MAV

the issue is still closed.

question please

Neither this issue nor one of the related issues(duplicates) had been in the
separate issue-tracker for  the showstoppers to 3.0.1 or 3.1.
There will be no release-meeting today, so the 3.0.1 will be released -
accordinly to the schedule and the date of code-freeze - without
alternations/changes and - just for the files - without even having problemized
the complaints of the users on a release meeting? 
Wow, for a more-or-less community-driven development this is hard stuff.
Or will the release of 3.0.1 already be delayed?


Comment 19 mikhail.voytenko 2008-11-03 17:13:16 UTC
I would kindly ask everybody to read carefully the whole discussion before
posting one more comment here. Thanks.


The issue is going to stay closed and my comments above describe why the issue
is closed. Everything that can be done for bug type of issue is covered by new
opened issue 95528 and issue 95530 ( please see the comment announcing them for
details ). This issue can not be closed as duplicate to the mentioned bugs,
since it also requests that other editors recognize the OOo3 file locking. That
needs system file locking support.

The request for system file locking support is a feature request, since the
current feature is based on the idea that the file system locking should not be
used. By the way, a new feature is nothing for OOo3.0.1 as I understood.

I have already written twice, that if somebody believes, that the system file
locking is necessary for him after the two mentioned issues are solved, he
should write a new feature issue to me for this. The system file locking usage
will not be introduced as a bugfix.

I am changing the summary to let it describe the problem better. The description
looks anyway not to be read ;)
Comment 20 billrobo 2008-11-03 23:09:19 UTC
A feature request (issue# 95809) has been raised to address file-locking in a
heterogeneous environment under OOo3.


Comment 21 Mathias_Bauer 2008-11-18 15:34:05 UTC
The fix for Issue 95809 will fix all the problems (including data loss) reported
for our new file locking. Please refer to Issue 95809 for further communication.
Comment 22 haneeshclt 2009-01-10 10:31:30 UTC
We are facing the same problem