Please have a look at this one. Thanks.

The investigation of the broken document shows that the first bytes are lost (
in the document I have investigated the first 2212 bytes were lost ). But the
rest of the document looks to have valid info. The fact that this info itself
contains reference to the current stream position means for me that at the point
of generation the stream still was OK. In other words the corruption seems to
happen after the package component has generated the valid file stream.

Changing the target to OOo3.2 for now.
The problem seems to be reproducible in DEV300_m51 as well ( only sometimes on
some machines ). Unfortunately I could not reproduce it myself till now.

removing CWS name tag from summary, as it is reproducible in MWS, too.

@mav: any news when this issue will be fixed. It's annoying to do the work again
and again, because a file is often corrupt.

I will try to integrate the fix ASAP, is there a database cws that will be in QA
next week?

We don't have a plan for such a CWS. If you want, and Marc agrees, you could
hijack dba32f. This one is brand-new, and intended for ongoing development, but
if it helps getting in your fix quickly, I'd offer it to you.

Yes , I agree. I will add the isssue to the CWS.

Thank you. I would suggest then to use fwk115. It was planned as StarOffice only
fixes cws, and should go to the QA begin of the next week. So the dba32f could
be used further, and we have one CWS less on automated tests queue next week.

I have just asked for the case that there is a CWS that will anyway be tested by
Marc next week.

As we have discussed with Marc, the issue stays in dba32f.

The possibility for race condition is fixed in dba32f.

mav->msc: Please verify the issue in dba32f.

reopen, because it's not fixed. The bug still happened exactly as before.

reassign back to developer

Hm, I must confess I could never reproduce the problem so it was a kind of blind
fix, I have fixed the only known for me possibility for the problem. Currently I
have no other idea what could go wrong on package side.

The problem looks to be that somebody works with the stream while the package
component is writing to it. It looks like seek(0) is done on the stream after
"database/log" file has been written.

There was another possibility to affect the result stream from another thread
while the package was commited. Should be fixed now as well.

mav->fs: Could you please build the cws again.

reassign to msc

verified in CWS dba32f

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba32f