Issue 105082 - Newly created empty database not opens (or: New AutoText changes group name)
Summary: Newly created empty database not opens (or: New AutoText changes group name)
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: DEV300m58
Hardware: Unknown Windows XP
: P2 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: christoph.lukasiak
QA Contact: issues@dba
Keywords: regression
: 105671 (view as issue list)
Depends on:
Blocks: 104695
  Show dependency tree
Reported: 2009-09-15 10:42 UTC by r4zoli
Modified: 2010-03-17 16:42 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

high-level "log" fil (395 bytes, text/plain)
2009-09-16 10:15 UTC, Frank Schönheit
no flags Details
mav->mhu: The patch seems to fix the problem, could you please review it. (2.55 KB, text/plain)
2009-09-16 21:19 UTC, mikhail.voytenko
no flags Details
Proposed patch (5.55 KB, patch)
2009-09-17 10:18 UTC, matthias.huetsch
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description r4zoli 2009-09-15 10:42:29 UTC
Create new database with File>New>Database, save it close file. 
Reopen file from menu File>Recent Documents, the file selection came up. 
It shows that database damaged.
File not opens in OOo 3.1.1 and m57, all shows file selection.
Comment 1 Frank Schönheit 2009-09-16 07:54:12 UTC
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 ...
Comment 2 mikhail.voytenko 2009-09-16 08:11:47 UTC
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

So I suspect that this is a combination of fixes that now affects the functionality.
Comment 3 Frank Schönheit 2009-09-16 08:23:43 UTC
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 ...
Comment 4 mikhail.voytenko 2009-09-16 09:06:39 UTC
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.
Comment 5 Frank Schönheit 2009-09-16 09:15:16 UTC
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 :-\
Comment 6 Frank Schönheit 2009-09-16 09:21:24 UTC
hmm, found no suspicious code change at all in dbaccess ....
Comment 7 Frank Schönheit 2009-09-16 09:29:29 UTC
the only other CWS which touched dbaccess in m58 is dbaperf3 - there, the bug
also does *not* happen.
Comment 8 Frank Schönheit 2009-09-16 09:52:24 UTC
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.
Comment 9 Frank Schönheit 2009-09-16 10:15:42 UTC
Created attachment 64783 [details]
high-level "log" fil
Comment 10 mikhail.voytenko 2009-09-16 10:25:48 UTC
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.
Comment 11 Frank Schönheit 2009-09-16 10:27:22 UTC
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 (and 4.1 to 4.1.1).

Now the first interesting item, which is for me: Why is there and, 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".
Comment 12 Frank Schönheit 2009-09-16 10:31:06 UTC
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.
Comment 13 Frank Schönheit 2009-09-16 10:52:01 UTC
note: omitting and 4.1.2, i.e. the superfluous commits of the root
storage, doesn't fix the problem.
Comment 14 Frank Schönheit 2009-09-16 11:48:35 UTC
I will commit a patch to CWS dba33a which prevents the superfluous commits
(, 4.1.1, 4.1.2). However, this does not solve the problem here ...
Comment 15 mikhail.voytenko 2009-09-16 21:17:55 UTC
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.
Comment 16 mikhail.voytenko 2009-09-16 21:19:37 UTC
Created attachment 64805 [details]
mav->mhu: The patch seems to fix the problem, could you please review it.
Comment 17 matthias.huetsch 2009-09-17 10:17:13 UTC
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 :-) ).
Comment 18 matthias.huetsch 2009-09-17 10:18:22 UTC
Created attachment 64809 [details]
Proposed patch
Comment 19 mikhail.voytenko 2009-09-17 10:56:24 UTC
mav->mhu: Thank you for the patch, it is now integrated into fwk117.
Comment 20 christoph.lukasiak 2009-09-21 16:48:40 UTC
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)
Comment 21 mikhail.voytenko 2009-09-21 20:50:39 UTC
mav->kla: Please verify the issue. Please let the storing/loading related
automated tests run additionally.
Comment 22 kla 2009-09-22 08:41:36 UTC
Reassigned to clu, as the responsible QA engineer. Cat 0 test are running, pls
cover the requested additional storing/loading related
automated tests. Thx
Comment 23 2009-09-22 11:28:30 UTC
just for the record: this bug breaks the following unoapi tests:

in CWS fwk117 they run again.
Comment 24 christoph.lukasiak 2009-09-23 09:31:29 UTC
verified in cws
Comment 25 stefan.baltzer 2009-09-23 14:52:09 UTC
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.
Comment 26 Frank Schönheit 2009-10-07 09:28:37 UTC
*** Issue 105671 has been marked as a duplicate of this issue. ***
Comment 27 r4zoli 2009-10-07 09:41:35 UTC
CWS fwk117 integrated into DEV300m61. I installed m61, and the orignal problem
present in this wersion on winXP.
Comment 28 Frank Schönheit 2009-10-07 09:52:42 UTC
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
Comment 29 r4zoli 2009-10-09 06:39:24 UTC
Verified in new build m61, and OOO320_m1. 
Comment 30 ab 2009-10-09 11:50:04 UTC
*** Issue 105719 has been marked as a duplicate of this issue. ***
Comment 31 christoph.lukasiak 2010-03-17 16:42:25 UTC