Issue 70147

Summary: invalid link entries to shared basic-librarys installed via unopkg add while a concurrent OOo process is running
Product: General Reporter: baumux <baumux>
Component: codeAssignee: ab
Status: CLOSED FIXED QA Contact: issues@framework <issues>
Severity: Trivial    
Priority: P3 CC: chris_mux, chrlutz, cno, issues, joerg.skottke, kpalagin, mux2005, oliver.brinzing
Version: OOo 2.0.3   
Target Milestone: ---   
Hardware: PC   
OS: Windows, all   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on: 80433    
Issue Blocks:    
Description Flags
uno package that contains a simple basic library none

Description baumux 2006-10-06 10:04:16 UTC
On windows a wrong behaviour could be observed using the following steps.

1. login as administrator on a Windows system

2. close all OOo processes including the OOo quickstarter

3. Install the attached uno package with "unopkg add --shared"

4. now there should be a link-entry inside the xml files 
<OOo2.0-path>\share\basic\dialog.xlc and ...\script.xlc pointing to the new
created basic-library at

5. open an OOo Writer

6. uninstall the uno package with "unopkg remove

7. now the above link entry should be deleted from the files
<OOo2.0-path>\share\basic\dialog.xlc and ...\script.xlc but this action was not
performed since the running office process still required the ressource.

8. Install the uno package with "unopkg add --shared"

9. now there should be a link-entry inside the xml files 
<OOo2.0-path>\share\basic\dialog.xlc and ...\script.xlc pointing to the NEW
temporary path ...\uno_packages\<TEMP_NUMBER2>\...  But this adjustment is not
done and the link still points to the invalid path

10. now close all OOo processes again

11. the wrong link-entries still don't get corrected, so OOo is now in an
inconsistent state which appears particulary when trying to access the shared
basic library as a user different to the administrator.
Comment 1 baumux 2006-10-06 10:07:08 UTC
Created attachment 39601 [details]
uno package that contains a simple basic library
Comment 2 kpalagin 2007-04-28 12:50:06 UTC
I am confirming behavior with 2.2 on WinXP, even though I do not see how it 
could create a problem.
Comment 3 clutz 2007-04-28 23:00:53 UTC
The inconsistent structure leads to an annoying errormessage (something like
"basic: script.xlc not found") when a normal user starts OOo and performes some
very simple harmless things. In most cases, the action the user wants to do is
getting chanceled and could not be performed until the structure gets repaired
by the admin manually.

This could be reproduced on user side doing the following steps:

1) bring OOo in an inconsistent state as described above.

2) switch to a normal user account

3) Start OOo-writer and call "Tools->Customize..."

4) now try to add a menuitem or a shortcut that calls a basic macro. You will
see that this step should NOT be possible due to the upcoming error message
(described above).

So it is possible to bring OOo into an inconsistent state where users can't
performs things they want to do and need to do where assistence by the admin is
required. This is no problem for only one user on one computer, but it is a
problem for large companies with a lot of computers/users when distributing a
custom uno-package that contains basic-macros.

Another thing is that the conditions for getting this inconsistency are complied
*by default* on all windows systems as the quickstarter-process is enabled by
default. The quickstarter also behaves as a process that blocks ressources that
 "unopkg remove ... --shared" wants to use. Admins very often forget to close
the quickstarter before upgrading a custom uno-package and will trigger the
above situation undeliberate.

Upgrading uno-packages that contain basic macros should be as easy as upgrading
uno-packages without basic macros. Our production component for example contains
complex jar-files and custom services (rdb-file) and the basic-code is only a
minor part of the component. All these other elements don't have problems with
the running quickstarter, wheras the view lines of basic code contained leed to
this issue.
Comment 4 thorsten.martens 2007-07-09 15:06:58 UTC
Please check again in a more recent build and describe, why this should be seen
as a defect (can only be defect if it has worked before or doesn't work as
specified or designed) and not as a wish for an enhancement. A "should be"
points to an enhancement and can't be seen as a defect.
Comment 5 clutz 2007-07-10 13:43:13 UTC
I tried this with OOo 2.2 and I still can confirm, that unopkg add/remove
corrupts the script.xlc/dialog.xlc files in the specified case. The behaviour
regarding the annoying error message on user side seems to be different than in
older versions of OOo (I was not able to reproduce the annoying error message
any more).

But I still think this issue is a bug as unopkg completely controls the content
of the two mentioned internal files and it in fact produces an incorrect state,
as retired invalid references are not removed. The incorrect state would not be
the problem if unopkg was able to repair it state automatically. But the
inconsistency leads "unopkg add" to refuse its specified and desired
functionality: To install a packages with all its included subcomponents. The
basic library is one subcomponent which must be installed correctly regarding to
the developers-Guide (chapter 4.9.1). After updating (removing and reinstalling)
an uno-package that contains basic-macros, the basic-macros of the new package
do not get active and the reference inside the script/dialog.xlc-files still
points to the retired package!
Comment 6 thorsten.martens 2007-07-10 14:04:17 UTC
TM->OF, JSK: please have a look, thanks !
Comment 7 Olaf Felka 2007-07-10 14:08:29 UTC
Comment 8 Olaf Felka 2007-07-10 14:11:11 UTC
@ jsk: Please have alook at this issue.
Comment 9 joerg.skottke 2007-07-11 07:44:13 UTC
I want to take part in this funny reassigning game ...

To JL: I do not have a suitable Windows machine currently (it's broken and won't
be back before next week). Can you please check this one? Thanks.
Comment 10 joachim.lingner 2007-08-06 16:08:57 UTC
In this scenario unopkg uses the Extension Manager from the running office and
should probably be able to modify the the two files.
Comment 11 joachim.lingner 2007-09-07 12:25:42 UTC
Comment 12 joachim.lingner 2007-10-18 14:13:23 UTC
Retargeted to 3.0.
Comment 13 cno 2007-12-02 21:10:51 UTC
added myself as cc
Comment 14 Oliver Brinzing 2007-12-03 16:52:58 UTC
added myself as cc

IMHO this should be fixed a soon as possible - it makes it nearly impossible to
remove basic extensions for end users ... 

Comment 15 joachim.lingner 2008-05-21 09:39:38 UTC
Comment 16 ab 2008-05-30 10:59:49 UTC
May become obsolete with the fix of i70283.
If not, I think the scenario is too complex to effect many users.
-> STARTED, OOo 3.x
Comment 17 mux2005 2008-05-30 11:24:15 UTC
> If not, I think the scenario is too complex to effect many users.

The steps to reproduce may seem complex but this is not some obscure fringe
case. This happens a lot when you're doing an automated update of an extension
on user PCs and as such is a big PITA for our admins. It basically boils down to
"If OOo  is running while you update an extension, thinks break." And making
sure no OOo is running is difficult. You can't just shoot down user processes in
an automated update.
Comment 18 ab 2009-01-30 12:04:40 UTC
This problem should have vanished with the fix of i70283 for OOo 3.0
(cws ab53 integrated into DEV 300 m24) as the mechanism for handling
Basic libraries in extension has been changed completely. Now the ex-
tensions are scanned during Basic initialisation and the extension
Basic libraries are only added at runtime. So the .xlc files are not
modified any more and so cannot be corrupted.

I set this issue to FIXED for now. If anyone still faces problems
like this, please let me know.