fs->mav: The resulting .odb file is not even a valid ZIP file anymore, so I
suppose this is something in the ZIP/storage implementation ...

The only suspicious change is the fix for issue 103266 ( that is quite similar
to this one ). But it was definitely tested in the cws, especially such a simple
scenario.

So I suspect that this is a combination of fixes that now affects the functionality.

Yes, I think so, too. I explicitly checked CWS dba32f, where issue 103266 was
fixed - the bug does not happen there. I'll also start investigating this as
soon as I have a suitable build environment for m58 ...

According to svn, the package and storage source code integrated in DEV300_m58
is the same as in dba32f cws. That does not mean that this is not a problem of
package, it just makes the investigation more complex.

Interestingly, the same does *not* hold for module dbaccess - it differs between
m58 and dba32f. Hmm. This doesn't mean it's a dbaccess issue, it just makes it
more likely :-\

hmm, found no suspicious code change at all in dbaccess ....

the only other CWS which touched dbaccess in m58 is dbaperf3 - there, the bug
also does *not* happen.

At the moment the document has been created, but not yet closed, the underlying
storage is still intact. The doc has been written once, i.e. the ZIP package
already contains content.xml and the like.
Now when the document is closed, quite some "commit" calls are issued on the
different sub/root storages, and this seems to be what corrupts the file. Will
investigate further.

Created attachment 64783 [details]
high-level "log" fil

The problem is that the stream is not truncated on rewriting for any reason. So
in case the document is becoming smaller the result file is corrupt.

Source code analyzing shows that the truncate() call should be called on the
stream. There seems to be something special in this scenario.

fs->mav: See the attached log file for what happens on the DBDoc-level,
regarding the storages. There's two interesting places there, one for you and
one for me :)

preface: we have a listener at the "database" sub storage, and every time this
storage has been committed, the root storage is also committed. This is the step
from 2.1.1 to 2.1.1.1 (and 4.1 to 4.1.1).

Now the first interesting item, which is for me: Why is there 2.1.1.1 and
2.1.1.2, i.e. why have we *two* listeners which commit the root storage when the
database storage has been committed? Will investigate this.

The second interesting item is for you: Why is the .odb file corrupted after 4.1.1?

Note: "intact/corrupted" was checked with by doing an "unzip -v foo.odb".

One more interesting observation: If I completely omit step 2.1, then the
document is *not* corrupted in step 4.1.1. That means that though steps 2.1.1/.*
do not corrupt the file itself, the seem to leave the storage/package
implementation in an inconsistent state, so the file is corrupted later on.

note: omitting 2.1.1.2 and 4.1.2, i.e. the superfluous commits of the root
storage, doesn't fix the problem.

I will commit a patch to CWS dba33a which prevents the superfluous commits
(2.1.1.2, 4.1.1, 4.1.2). However, this does not solve the problem here ...

Indeed, the package tries to truncate the stream, but it does not work in the
scenario. The truncation mechanics does not work correctly in case data is
written to the stream afterwards, the contents of the old buffer are written
again. The problem seems to be the result of the new buffered IO implementation
from mhu20.

Created attachment 64805 [details]
mav->mhu: The patch seems to fix the problem, could you please review it.

mhu->mav: Indeed, the "setSize()" implementation is insufficient, stupid me :-(
Your patch seems to be okay, but I will attach another version (which I like
better :-) ).

Created attachment 64809 [details]
Proposed patch

mav->mhu: Thank you for the patch, it is now integrated into fwk117.

additional qa comment: save db file with a dev300m58 (or corresponding cws based
on this milestone) -> open with a f.e. dev300m57 => shows the issue ('filter
selection dialog' opens -> should open the saved db file)

mav->kla: Please verify the issue. Please let the storing/loading related
automated tests run additionally.

Reassigned to clu, as the responsible QA engineer. Cat 0 test are running, pls
cover the requested additional storing/loading related
automated tests. Thx

just for the record: this bug breaks the following unoapi tests:
 sw.SwXAutoTextEntry
 sw.SwXAutoTextGroup

in CWS fwk117 they run again.

verified in cws

As mst noted, this issue also concerns AutoText handling.
Symptom: AutoText group name is damaged after a new AutoText entry is added.
This brought up a warning in AutoTest w_updat.bas (Testcase tEditAutotext):
"Unable to delete created autotext". 
Cat_0 test "w_updat" ran OK on CWS fwk117 and I also verified the fix with this
scenario in CWS fwk117 manually.
To ease string queries, I noted this "B scenario" in the summary.

*** Issue 105671 has been marked as a duplicate of this issue. ***

CWS fwk117 integrated into DEV300m61. I installed m61, and the orignal problem
present in this wersion on winXP.
Reopen. 

Sigh. There have been build problems with m61, which have been discovered only
after uploading the snapshot. In my understanding, it is currently completely
unknown to which extent the version is broken, but it definitively *is* broken.
At the moment, I try to convince the people responsible for the snapshot
releases of that view, and to announce that.

So, for the moment please refrain from testing this version further.

Will nonetheless keep this issue open to check it again once a new build is
available.

Verified in new build m61, and OOO320_m1. 

*** Issue 105719 has been marked as a duplicate of this issue. ***

close