setting new target 

typo in summary

The test program starts OOo serveral times, opens a spreadsheet and fills in
some data. This causes a call into the extension manager. When it is
initialized, then it copies a common.rdb to a common_.rdb or vici versa. These
files are in 
OpenOffice
3/share/uno_packages/cache/registry/com.sun.star.comp.deployment.PackageRegistryBackend.

The copying is done by the system function CopyFile which fails. GetLastError()
returns 1224 which represents this error: ERROR_USER_MAPPED_FILE,  The requested
operation cannot be performed on a file with a user-mapped section open. 

The common.rdb or common_.rdb are locked by the client program (runtests). When
the client starts then it creates the cli-uno bridge in its process, which
bootstraps UNO using the libraries from the office installation. Bootstrapping
UNO includes setting up the service manager, which causes all services rdb
files, such as common.rdb, to be opened. The file will then remain opened as
long as the client runs. When the client restarts OOo then OOo cannot overwrite
the common.rdb, which is still opened by the client. 

This problem has become visible, because OOo is now bundled with a couple of
extensions. Opening a calc document will now lead to a call into the service
manager.
The bug does only affect the cli-uno bridge, AFAIK.

The work around is to use the quickstarter of OOo.

Possible fixes are:

1. Allow adding / removing services of the loaded rdb files

2. Invent  another mechanism of how the extension services  are registered

3. Write a real cli-uno remote bridge. The current bridge is actually an
inprocess bridge, which was intended for using cli-uno components.

All three solutions are time consuming and to risky for 3.1. I therefore suggest
to retarget this issues as long as OF can verify that the workaround works.

See also issue 93914.

Another workaround is that the user does not have write access to OpenOffice
3/share folder.

Not happy with target 3.2 but: To risky to fix.

Removing the blocked issue id.

I thought that I caused the problem by allowing to install shared extension in
OOo 2.3 but this is not the case. The copying of the common.rdb also happens in
OOo 2 final (m124). What was different then was that the extension manager
dialog checked if the office is runnging. If this was the case then it did not
allow to install/remove shared extensions. 

That the original problem has been existing for ages but only became obvious by
the now bundled writer2latex extension.

@of: This is actually no regression. Consider deleting the key word.

Sun internal issue 159202 is also caused by this.

The only useful fix is to prevent this copying of the rdb. This would either
require read and writable registry files, or the shared extensions must be
installed before UNO is bootstrapped in OOo. Both solutions would cost quite
some time to implement.

Maybe there is a simple solution: Only copy the common.rdb (and change the
unorc, etc) whenever a shared extension is being installed. That is what now is
done every time the extension manager is initialized will then only be carried
out on demand. Because we say that no other instance of OOo may be running when
installing shared extensions, we cannot run into problems. Of course
boostrapping and UNO environment which is done when using a cli client program
must also be regarded as 'running another instance'.

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

target 3.3

@QA: Please test extensively adding and removing extension. One should add some
extensions, restart OOo and check if the extensions are still there and working.
Use extensions which contain c++ and Java services.

Further testing can be done by running the test case for Sun internal issue
159202 (Sun internal) and running the cli test program ( OF knows about this).
Then install the sun presentation minimizer extension or any other extension
which uses help files. Running the test with a master office will fail with an
exception (start the test from a console, to see the exception).

.

As i'm not familiar with this stuff, i change owner.#

@HI: You submitted and verified a similar issue, please take over.

The fix looks good for me in cws jl145.

verified