Apache OpenOffice (AOO) Bugzilla – Issue 70147
invalid link entries to shared basic-librarys installed via unopkg add while a concurrent OOo process is running
Last modified: 2017-05-20 10:34:04 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.
Created attachment 39601 [details] uno package that contains a simple basic library
I am confirming behavior with 2.2 on WinXP, even though I do not see how it could create a problem.
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.
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.
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!
TM->OF, JSK: please have a look, thanks !
reassigned
@ jsk: Please have alook at this issue.
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.
In this scenario unopkg uses the Extension Manager from the running office and should probably be able to modify the the two files.
.
Retargeted to 3.0.
added myself as cc
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
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
> 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.
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.