you can use this extension for testing
http://extensions.services.openoffice.org/project/ctoo

Set target and reassigned

CC me.

I changed the name of the userlayer in bootstrap.ini to Staróffice (adding an
accent to the o). This causes the Extension Manager to fail with "Couldn't open
registry file [...] types.rdb for reading". The extension Laurent pointed to was
used. Weird, retrying with fresh setup...

the main problem i detected is that uno_packages is in a path like
C:\Documents and Settings\Benoît The User\Application 
Data\OpenOffice.org\3\user\uno_packages\cache\uno_packages

that is not handled correctly when registering an oxt containing a jar with
unapkg add

reproduced on winXp and win7. No probleme if i use "Benoit The User" instead of
"Benoît The User"

The sample extension appears to have a broken types.rdb which cannot be loaded.
Trying other...

I'm still unable to reproduce as unopkg quits with an error while enabling
types.rdb even on a system that otherwise behaves normally (other extensions
install flawlessly). Is it possible that the sample extension
terminologie-1.0.4.oxt is broken? 

Tried with weblog publisher extension (which comes with jars as well), no
problem - works ok using both Extension Manager UI and unopkg.

doing some more tests, seems the legnth of the user name (and then the path) is
quite important
reproduced with "Benoît the User" but not "Benoît"

Nope, "sun-weblog-publisher.oxt" was installed into a user directory called
"Benoît The User" - it would have failed as well.

@laurentgodard:  "the legnth of the user name (and then the path) is
quite important":  That is issue 50885, otherwise probably unrelated to this
issue here.

What I could reproduce is the following:  Using OOo OOO320m8 on a random
platform (tried wntmsci12.pro, unxlngi6.pro, unxsoli4.pro), with a random user
installation directory (with and without accented letters), adding
terminologie-1.0.4.oxt as available from
<http://extensions.services.openoffice.org/project/ctoo> fails, apparently due
to problems reading the contained types.rdb:  While with a DEV300m31 regview the
contained types.rdb is processed fine, DEV300m57 regview complains that "open
registry 'types.rdb' failed" (I have no rev. between DEV300m31 and DEV300m57
available to tell where exactly it started to fail, but all revs. DEV300m57 and
later I have available appear to fail, incl. the OOO320 revs.)  [Changed summary
accordingly.]

@mhu:  CWS mhu17 ("Module 'store' bugfixes and performance optimizations") has
been integrated into DEV300m44, in between m31 and m57, so maybe a regression
was introduced there causing problems reading that specific rdb file.

thanks a lot for your tests
i'll follow #50885

btw, the terminologie.oxt istall correctly with "Benoit The User" here. No error
when using unopkg add
(so the problem is not only a length-path one)

thanks again

Created attachment 66977 [details]
hexdump of unreadable types.rdb (terminologie extension)

Created attachment 66978 [details]
hexdump of types.rdb (from ooo/ure/share installation)

Created attachment 66979 [details]
diff of hexdumps at offset 0x0200

source code for the extension terminologie.oxt
http://bitbucket.org/rpelisse/ctoo/

HTH

The "types_rdb.diff" attachment shows what makes this extension's "types.rdb" 
different from others ...

--- ooo_types_rdb.txt	2010-01-04 18:41:43.000000000 +0100
+++ ext_types_rdb.txt	2010-01-04 18:37:01.000000000 +0100
@@ -30,28 +30,28 @@
-00000200  22 03 19 58 c4 c3 20 2c  00 02 00 00 00 02 40 00  |"..X.. ,......@.|
+00000200  00 00 00 00 ee 83 a3 39  00 02 00 00 00 02 60 01  |.......9......`.|

i.e. at offset 0x0200 it has "00 00 00 00" where "22 03 19 58" is expected (a 
magic number identifying the block at this offset).

To be able to better understand this issue, I'd need to know which tooling 
(version) has created this file (types.rdb) => needmoreinfo

removed from stopper list for 3.2 since this does not seem a general problem and
more information is needed. set target 3.3

I try to understand the problem for corrections. 

I'm not sure to understand. 
I build the ctoo module under Ubuntu 9.10. 
You indicate that the file would be different between types.rdb version 
in the component, and the version in ooo/ure/share. 
Where is this directory? 
I can not find it. I have a /usr/lib/ure/share, but there is no types.rdb. 

In Windows XP: 
I can find: 
- C:\Program Files\OpenOffice.org3\URE 
- C:\Program Files\OpenOffice.org3\Basis\share 
- C:\Program Files\OpenOffice.org3\URE\misc\types.rdb 

This does not match your description. 


I build the component with installed OpenOffice SDK from Ubuntu
The build of the project does invoking idlc and remerge, installed by Ubuntu. 

/usr/lib/openoffice/basis3.1/sdk/bin/idlc.bin Version 1.1 
md5: f870a631945f49d287443ae2fac559fb /usr/lib/ure/bin/regmerge 

The ant command to build types.rdb is as follows: 

		<exec executable="${remerge.exe}"
		      failonerror="yes"
		      failifexecutionfails="yes">
		    <env key="LD_LIBRARY_PATH" path="${OOo_HOME}/ure/lib/"/>  
		    <arg file="${target.generated.types}"/>
		    <arg value="/UCR"/>
		    <arg file="${target.generated.urd}/CtOO3.urd"/>
		    <arg file="${target.generated.urd}/Result.urd"/>
		    <arg file="${target.generated.urd}/XCtOO3.urd"/>	      
		</exec>

Can you enlighten me on the problem? Is it a bug of my component or Open office 
?

Hi Laurent, Philippe,

Thanks for your clarifications => removing "needmoreinfo" keyword.

The mentioned types.rdb from my ooo installation (ubuntu 9.10 also) is located 
under <ooo>/ure/share/misc/types.rdb (with <ooo> meaning <install root> or 
/usr/lib in this case).

Installing package "openoffice.org-dev" (OOo SDK) onto my system (ubuntu 9.10) 
and obtaining a clone of your source code, I could reproduce your problem. Thus, 
the distribution provides an SDK that creates corrupt *.rdb files, i.e. the idlc 
generated "ucr/*.db" files, and the regmerge created "types.rdb".

Obtaining a copy of the vanilla OOO310_m19 tag from svn.services.openoffice.org 
(OOo 3.1.1), and building up to module "udkapi", I can verify that the vanilla 
source code generates correct *.rdb files.

Looking up the go-oo.org / ooo-build patches for OOo 3.1.1, and reviewing the 
"store-core.diff" patch shows at least 2 bugs, the fatal one being:

<quote>
--- store/source/stortree.cxx.old	2009-04-02 10:44:48.000000000 +0000
+++ store/source/stortree.cxx	2009-04-06 16:42:11.000000000 +0000
@@ -65,15 +65,15 @@ OStoreBTreeNodeData::OStoreBTreeNodeData
  */
 void OStoreBTreeNodeData::initialize (void)
 {
-	base::m_aGuard.m_nMagic = STORE_MAGIC_BTREENODE;
-	base::m_aDescr.m_nUsed  = base::size() + self::size();
-	self::m_aGuard.m_nMagic = 0;
+	base::PageHeader ().m_aGuard.m_nMagic = STORE_MAGIC_BTREENODE;
+	base::PageHeader ().m_aDescr.m_nUsed  = base::size() + self::size();
+	self::PageHeader ().m_aGuard.m_nMagic = 0;
</quote>

with the following suggested fix:

-	self::PageHeader ().m_aGuard.m_nMagic = 0;
+	DataRepresentation ().m_aGuard.m_nMagic = 0;

Thus, the bug is not in the vanilla source, and I need to resolve this issue as 
"wontfix".

Regards,
Matthias

thanks a lot matthias !!!

i relayed to a go-oo guy

wontfix -> closed

FYI, just pushed a fix for this into ooo-build-3-1-1, at least debian will
update the packages shortly.