Apache OpenOffice (AOO) Bugzilla – Issue 85794
Reimplement file locking using an additional file.
Last modified: 2008-06-24 08:23:29 UTC
Currently the system file locking does not always work as expected in case of using of network file systems. To avoid the problems the file locking will be implemented using an additional lock-file. Currently it is planned to do it only for own file formats.
*** Issue 54567 has been marked as a duplicate of this issue. ***
cc tbe
The implementation in calcshare2 is ready. All the known bugs are submitted separately.
Please verify the issue.
Verified. Looks OK to me on CWS calcshare2.
*** Issue 54586 has been marked as a duplicate of this issue. ***
Created attachment 53109 [details] TestCaseSpecification
I tested the filelocking implementation of OOo3 (300m2 Rev 9301) on Windows and found the following bugs 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. Please add these two usecases to your testcase and test again! Please notice that these usecases are real-world usecases which will occur regulary in our heterogenous environment while introducing OOo3. In this point the file-locking implementation of OOo2 is better than OOo3 as there is no data loss with OOo2 in the same usecases. I think this would be a blocker for us not to use OOo3.
IMO this issue is not solved completely. Please read my test result from Jun 13.th for the reason why.
mav->clutz: This issue is solved as it was planned. Please read the description carefully, it is explicitly mentioned there that the locking will be done only for OOo formats. If you are not satisfied with the decision not to lock the alien formats files, please open a new issue and send it to me, and do not reuse the issue that is correctly solved.
.