«BTW: of course the already saved file is not affected by the problem, it's just that the document loaded in memory gets into an unvalid state.»
That was my understanding : the file saved to a hard disc folder other than «Temp» remains unaffected by the cache-clearing manoeuvre, but the document that is open - and which is found in «Temp» - is deleted. I agree that it would be wise to write a brief warning to the effect that all documents in «Temp files» will be deleted by «clear caches» and suggesting that desired documents first be saved to a permanent file that would appear on the screen when the «clear caches» option is selected.... Henri 2007/1/19, Mathias Bauer <[EMAIL PROTECTED]>:
M Henri Day wrote: > Mathias, as Mr Innes described the problem, he had saved the files in question several hours previously to clearing his caches, but had left the files open. My understanding - and my point - was that in the event he had saved a file to a folder other than «Temp», say, «My Documents», that file in the state in which he had saved it, would not be affected by his clearing his caches. If, as you say, OOo saves on-going work to the «Temp» folder, this would mean that the changes introduced in a given file after it had been saved to «My Documents» would be wiped out, but the earlier, saved version would remain unchanged. Is my understanding of the situation erroneous ? Yes, but this is not your fault, there are some tricky parts in how OOo accesses the single streams in its zipped file format and this usually is known only to the developers. BTW: of course the already saved file is not affected by the problem, it's just that the document loaded in memory gets into an unvalid state. For performance reasons OOo keeps *editable* or seekable streams (mainly embedded objects and graphics) open because otherwise they had to be unzipped again and again. They are not kept in memory (that could be a lot!) but as temporary files. When the document is saved the current state of all these streams is zipped into the target file. Even after this these streams remain there and OOo still uses them. Why deleting them and unpacking them again later? So if you remove them you "steal" OOo its working data. You might ask why OOo doesn't keep a lock on these files if it needs them so badly. The answer is simple. File Handles are a limited resource even today though on single user systems you only rarely will reach this limit. On multi user systems though (Linux/Unix or Citrix servers) file handles per user are even more limited and reaching the limits can easily happen if you don't plan for avoiding this. We had cases where opening even one single document with a lot of embedded content made OOo crash because we got out of file handles. It is not uncommon to have a limit of 512-1024 file handles per user! So we now release all file handles (means: release our locks) after using a temporary stream and reacquire them when the stream is needed again. There have been some plans to overcome these problems with a different approach to handle temporary content but all of them ended in a measurable performance loss. For the time being we have to accept that it is necessary to leave all files in OOo's temp folder untouched. The safest way is as I described: either remove all tools that clear the temp folder while the computer is used or use an own temp folder for OOo. Perhaps we should think about an error message that warns users as I think this problem should be easily detectable. 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.
