Apache OpenOffice (AOO) Bugzilla – Issue 91015
data loss using concurently OOo3 and another editor in the same network
Last modified: 2009-03-10 09:41:43 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 access. Please add these two scenarios to your testcase and ensure that there is no way to lose data using OOo3.
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.
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.
*** Issue 95060 has been marked as a duplicate of this issue. ***
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 network!! regards
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!
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?
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.
.
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.
The only way to request the old behavior ( system file locking usage ) is to submit a new feature request to the feature committee.
"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...
*** Issue 95608 has been marked as a duplicate of this issue. ***
What is the process required to submit a feature request to the features committee? Notes: 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.
I confirmed.
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.
@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.
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?
==> 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? Martin
I would kindly ask everybody to read carefully the whole discussion before posting one more comment here. Thanks. mav->mhatheoo: 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 ;)
A feature request (issue# 95809) has been raised to address file-locking in a heterogeneous environment under OOo3. Refer: http://www.openoffice.org/issues/show_bug.cgi?id=95809
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.
We are facing the same problem