Jan Holesovsky wrote: > Hi Mathias, > > On Wednesday 10 January 2007 11:44, Mathias Bauer wrote: > >> > Please remember that no locking was the default until 2.0 >> > (http://www.openoffice.org/issues/show_bug.cgi?id=29425) so I guess if >> > this were a real problem, we would have had some crashreports already. >> > (Or do we have them?) >> >> Yes, we got crash reports for such cases. We already made the code more >> robust, maybe even robust enough so that we will crash only rarely >> nowadays. But at least the document can become unusable in case it >> contains embedded content like e.g. objects. This will lead to data loss >> because then the document can't be saved anymore. Bad user experience. > > Interesting. Can you please send me a step-by-step description how to > reproduce this with locking turned off (unset SAL_ENABLE_FILE_LOCKING). That > would be extremely helpful.
The problem was that in OOo1.x we had to close the document stream before we saved a document. In OOo2.0 we made the code more robust by avoiding this. So many scenarios that lead to crashes or i/o erros in OOo1.x without locking aren't available with OOo2.0 anymore. It looks as if as long the stream is kept open neither deleting nor changing the underlying file creates any problems nowadays, for file access both on a local Linux machine and via NFS. There are a lot of other scenarios to test but the situation has improved a lot. No guarantees though. I think before we come to a final judgement we need to think a little bit more but meanwhile I'm more optimistic. :-) > Excel is the program to test. Try again with a worksheet - it gives you > similar choices after you try to open it in the second Excel instance. And > then turn on the shared workbook functionality (Tools -> Share Workbook). > You'll see that now no locking is involved, anyone can open and save it > without any additional warning. OK, I didn't know that Excel offers more stuff here. Meanwhile I see that even data loss (that was a great problem when no locking was available in OOo1.1) isn't a fundamental problem. What I overlooked is that in your scenario all clients using the file without a lock are aware of that and so they will do a merge step before they save. No client will overwrite changes made by another one (as in OOo1.x). The worst thing that can happen is that a "shared" file is opened by another office process that doesn't take part in the sharing and so locks the file. This will prevent the "sharing" clients from saving the document. Or did I overlook another detail? ;-) >> Well, I could agree if you implemented something completely new, but >> here we are talking about something that the competition has for years. >> Why not implementing it completely or at least sufficiently if it is >> known already that it could be done better than just having the basic >> steps? > > What exactly do you mean? Niklas just wrote that merging works sufficiently > (which is the same that my tests showed). Am I supposed to spend half a year > testing whatever works and what does not, another half improving the latter, > and then come up with the shared worksheets in another half a year? Sorry, > but my employer wouldn't pay this - they want to see the shared worksheets. > If they see that there are limitations in the merge, they'll allocate more > time to fix that. No, merging must be used anyway and so we either take what we have and fix the merging bugs (or missing features) later or we don't do it at all. I was talking about using a server for managing the concurrent access because this should solve all problems (except the problem of unsufficient merging abilities of course as the server still needs to merge changes). The question remains what users expect to be mergeable. My personal opinion is that at least changing cell content in any way, adding new cells or changing cell and table attributes should be covered. I don't think that OLE objects, graphics etc. are that important. But YMMV (or Niklas' mileage ;-)). >> And more over there is no API *below* osl that works on all platforms. >> So it's quite unlikely that osl will get such an API. > > Really? fcntl() on unx & Mac OS X, > http://msdn2.microsoft.com/en-us/library/aa365203.aspx on Win32, what else? It doesn't work on Win9x. Well, that might be not interesting anymore nowadays. So you should talk to Hennes Rohling (HRO) wether an advisory lock API in osl makes sense under these preconditions. If you offered to implement it I could imagine that you wouldn't face many complaints. :-) For Win9x we could perhaps try to emulate the locking/unlocking by reopening the file internally (inside osl's stream abstraction). That isn't perfect (as you pointed out) but definitely better than having nothing. >> Where is the problem with reopening the file? So >> >> - try to open the file >> - if it can't be opened for writing open it read-only >> - if the user requests write access offer to create a copy of the file >> and try to merge it back when the user wants to save >> >> When you want to save >> >> - try to open the "real" file for writing >> - if it works merge the files and save the merged document >> - if it fails offer a way how the user can maintain his local copy until >> the file is available again > > Sure, that would be nice if it was possible [and I'd appreciate pointers to > the code where I could hook this if I'm wrong]. > > Unfortunately I did not find a better place than ScDocShell::Save() and > ScDocShell::SaveAs(), see > http://svn.gnome.org/viewcvs/*checkout*/ooo-build/trunk/patches/src680/shared-worksheets.diff?rev=8553 > > [proof of concept implementation modulo the locking], method > LoadAndMergeSharedWorksheet(). Later than in Save() and SaveAs() methods, > various transformations happen before the 'open the "real" file for writing' > starts, and of course after the transformations it's too late to merge. I will have a look on your code to understand you approach better. Please give me some time to understand if and how my suggestions fit into your scenario. Questions remain: - Can we accept that the feature doesn't work (or bears some risks) on Win9x? - If we take for granted that using unlocked files works for us under all circumstances on Linux (looks so), are we sure that changing or deleting of unlocked but opened files also works for us on all relevant platforms and so doesn't create a problem? - How does it work in heterogeneous networks? - And if we discover problems, can we accept them or must we drop the ability to save at everytime without any warnings? Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
