Hi Mathias, On Thursday 11 January 2007 11:41, Mathias Bauer wrote:
> > 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. :-) Glad to hear that :-) > 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? ;-) Good point, older OOo version that is not aware of the shared worksheets functionality could be really a problem. I guess that the solution here is to provide the user with the possibility to 'Save As' the document if we cannot obtain the lock (in a certain amount of time?). (Eg. when the file is locked, we could issue a 'Waiting for other users to save the changes...' dialog box with [Save As] and [Cancel] buttons.) > >> 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/sh > >ared-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. I've split the above .diff into two to make them more readable: http://svn.gnome.org/viewcvs/*checkout*/ooo-build/trunk/patches/src680/modal-changes-dialog.diff - implements modal version of the changes dialog http://svn.gnome.org/viewcvs/*checkout*/ooo-build/trunk/patches/src680/shared-worksheets.diff - the functionality itself > Questions remain: > > - Can we accept that the feature doesn't work (or bears some risks) on > Win9x? Luckily, Stephan pointed out that even Win9x should work. > - 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? We should test this thoroughly, yes. > - How does it work in heterogeneous networks? For sure this functionality is not going to be compatible with the MS Office feature ;-) Otherwise it should [theoretically] work well if the locking works well for the network; according to what I found eg. Samba supports that, so we could be OK... But of course, should be tested as well. > - And if we discover problems, can we accept them or must we drop the > ability to save at everytime without any warnings? I'm not sure that I understand you correctly. But if you mean what to do if the file is locked for too long, I think we should present the user with the problems and allow her to do 'Save As' as described above. Thank you, Jan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
