Apache OpenOffice (AOO) Bugzilla – Issue 94637
an open edition of a file is not marked/recognisable as 'busy' to other users of the system; edits are lost or overwritten
Last modified: 2008-11-24 20:31:53 UTC
= Abstract = An .odt file that is open and actively edited by one user of Mac OS X can be concurrently opened and edited by other users of Mac OS X. Other users' edits are lost (over-written?) without warning. Might this be because the file is not marked as open/busy? = Detail = The other users are _not_ aware of the first user's edits in progress; their opening of the file is not forced to read only. As the other users save their edits to the file, no error is presented. Everything appears fine. As the first user subsequently saves their edits to the same file, no error is presented. Everything appears fine. In fact, there is no trace of the edits that were supposedly saved by the other users. = Environment = Mac OS X 10.5.5. = Background = AFAIR I first noticed this bug whilst troubleshooting under issue 94591 following a comment at GullFOSS concerning multiple users. = See also = Issue 93741, I shan't guess whether what I'm reporting is related to echatzik's report. = Priority = Initially P2, > User data is corrupted in an easy-to-encounter way However: if the nature of the bug is as I suspect, then I'm tempted to suggest P1. Files that are open and/or busy _without being marked/recognisable as such_ may cause problems to other applications in ways that are very unpredictable, very difficult to troubleshoot.
Note to self, or to anyone: * maybe experiment with OOo 3.x on multiple platforms aiming to concurrently open/edit a single file on an SMB/CIFS server — to determine whether the issue is limited to OOo on Mac OS X * maybe experiment with OOo 3.x on Mac OS X on multiple computers aiming to concurrently open/edit a single file on an AFP server.
@mav: your changes for issue 92735 look related. Care to comment?
@hro,mav: I guess he's talking about file locking, any comments ?
Discussed at http://wiki.services.openoffice.org/wiki/Log_Mac_Meeting_October_8th_2008 I see also issue 92433 discussion of locking but (relatively uneducated) I don't know whether we should here (Mac OS X, let's assume 10.5) distinguish between locked, busy etc..
The Version field refers to OOO300_m8, although there is currently no known way to reproduce the scenario if both users use OOo 3.0. Are you sure that the second user uses OOO300_m8 as well? The file locking used in OOo 3.0 is based on the additional lockfile and thus is not recognized by other programms including OOo 2.x
According to pl a third-party application was used in the mentioned scenario. So the office behaves itself as designed. OOo2.x has used file system locking to lock files. Unfortunately it does not work as expected in heterogeneous systems ( sometimes files are not locked as expected, or even worse they stay unexpectedly locked ). Thus to have a more consistent locking mechanics the OOo3.0 was switched to own file locking based on lock file. The new locking solution has other minuses mentioned in this issue, the lock is recognized only by OOo3.0. Actually we had to choose the lesser of two evils. The problem here is that some users use another measures, and for them the selected evil is not the lesser one probably. Setting currently to "will not be fixed", since the current plans is to stay with the selected way of file locking.
close the invalid issue
With apologies for re-opening: I'm uneasy about closure of an issue that demonstrated loss of data. True: the situation in which loss was demonstrated may be peculiar. However: in any situation, a loss occurring with no error, warning or explanation to the user 'feels wrong'. If > the lock is recognized only by OOo3.0 then, how could two users of OO0300m8 open and edit the same file resulting in loss of one user's data? (Did a fix for the issue follow milestone 8?) I can't pretend to fully understand the technical aspects, I do appreciate more generally a 'lesser of two evils' approach, but something feels not quite right about this one.
mav->grahamperrin: That sounds like a misunderstanding. Please read my last comment carefully. I have written there, that as I understood the problem is only reproducible if the second user uses a third-party editor or OOo2.x. You initial comment describes the problem for other application as well. There is currently no known reproducible scenario, when two users can open the same document for editing using OOo3.0 at the same time. Till now this scenario was not described in this bug. If you know one, please provide the details here.
Certainly, I wasn't clear enough in my opening report. As I had shifted focus from 94591 (where I was in 'works for me' mode) I omitted to include relevant detail. A highlight from that other issue: > plain text file To reproduce the loss of data involving two users of OOo 3.0.0 on Mac OS X: 1. have a plain text file, world-writeable: /Users/Shared/test/test.txt 2. as Mac OS X user 'A', open and edit that file using OOo 3.0.0, save (keep current format), edit some more without saving 3. fast user switch to the Guest Account of Mac OS X 4. launch OOo 3.0.0 5. command-O 6. command-shift-G 7. /Users/Shared/test 8. open test.txt 9. edit and save the file — edition and save are both apparently without error 10. log out from the Guest Account 11. continue working as user 'A' 12. continue using OOo to edit and save the same file /Users/Shared/test.txt 13. save and quit Result: no trace of the edition that was apparently saved without error by the Guest Account user of OOo 3.0. Is the locking limited to only certain types of file? Are plain text .txt files more vulnerable?
> * maybe experiment with OOo 3.x on Mac OS X on multiple > computers aiming to concurrently open/edit a single file on an > AFP server. Testing only briefly with two computers (one Intel, OOo 3.0) (the other PowerPC, non-QA'd OOO300m9 (Build:9358) attempting to edit a single plain text .txt file created by the first OOo user: * I can not cause loss of data (the second user's opening of the file is read-only). In this environment, I guess that AFP takes care of locking.
> * maybe experiment with OOo 3.x on multiple platforms aiming to > concurrently open/edit a single file on an SMB/CIFS server Testing only briefly with SMB service provided by Mac OS X Server 10.5.5, at a share point for which neither oplocks nor strict locking are enabled, here too I can not reproduce the issue; the second user finds as read-only the file that the first user is editing.
Summary: Thanks for responding with politeness to the re-opening of this ticket! The brief tests with AFP and SMB are reassuring. The single computer, multiple user environment in which I strayed from Apple defaults — allowed world write to a file within /Shared — is exceptional; and the loss of data is demonstrated using a plain text .txt file (not ODF) but still, I'm just a little uneasy. P4 or P5 uneasy, if you like :) I know next to nothing about NAS but if I had an NAS device, I'd be tempted to test there, next… Regards Graham
Ok, I see. The problem with alien document formats is already fixed for the issue 95528. The original problem described in this bug will be fixed by allowing to turn the system file locking on ( in addition to OOo3.0 locking mechanics ), this feature will be implemented for the issue 95809. I am closing the issue as a duplicate to one of the mentioned issues. *** This issue has been marked as a duplicate of 95528 ***
clsed the duplicate