Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||invalid link entries to shared basic-librarys installed via unopkg add while a concurrent OOo process is running|
|Status:||CLOSED FIXED||QA Contact:||issues@framework <issues>|
|Priority:||P3||CC:||chris_mux, chrlutz, cno, issues, joerg.skottke, kpalagin, mux2005, oliver.brinzing|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:||80433|
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 SimpleBasicLibAsUnoPkg.uno.pkg --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 <OOo2.0-path>\share\uno_packages\cache\uno_packages\<TEMP_NUMBER1>\SimpleBasicLibAsUnoPkg.uno.pkg\basic\mylib\dialog.xlb (script.xlb) 5. open an OOo Writer 6. uninstall the uno package with "unopkg remove SimpleBasicLibAsUnoPkg.uno.pkg --sharedâ€œ 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 SimpleBasicLibAsUnoPkg.uno.pkg --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 ...\uno_packages\<TEMP_NUMBER1>\... 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 ... Oliver
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.