Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||user directory file size grows to 160mb due to bundled extensions|
|Product:||Installation||Reporter:||Oliver Brinzing <oliver.brinzing>|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||anrdaemon, awf.aoo, delest.hagar, doudou1976, hdu, issues, jsc, k_a_r_l_o_, oliver.brinzing, pescetti|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:||120033, 120082|
Description Oliver Brinzing 2012-04-23 17:45:20 UTC
Created attachment 77484 [details] user dir after installing aoo3.4rc1 i noticed the oo user dir has now about 160mb file size caused due to installing bundled extensions (for example dictionaries, presenter console, presentation-minimizer,...) bundled extension are copied to: \user\extensions\tmp (~80mb) *and* \user\uno_packages\cache (~80mb) imho this can cause: - performance issues if oo user dir is on a network drive - storage space problems
Comment 1 Olaf Felka 2012-04-26 14:29:55 UTC
This is unneeded as the extensions can be installed as shared extension in the office layer. Pumping up the userlayer is not a good idea.
Comment 2 Ariel Constenla-Haile 2012-05-16 06:44:19 UTC
*** Issue 119359 has been marked as a duplicate of this issue. ***
Comment 3 Hagar Delest 2012-05-22 06:26:20 UTC
th_en_xx_v2.dat is installed for each English flavor of the dics! Since it is 18MB, it makes 4 times exactly the same file! Please send only one flavor in the default installation!
Comment 4 Andre 2012-05-25 12:09:52 UTC
There are different ways to fix this: a) Find out why there is (and remains) a tmp directory that contains a large amount of data. b) Find out why a couple of extensions need 80mb of data. c) Install the extensions only once not per user. For this to work c1) Create a small binary/script that is run by the administrator that installs the extensions system wide.
Comment 5 Andre 2012-05-25 12:12:57 UTC
One part of the problem is not merely technical. Due to the non-category A licenses of (some of) the extensions we are not allowed to unpack them when the installation sets are created. Therefore detecting identical files used in more than one extension and removing the duplicates is not possible at that stage. Doing it later on first run when the extensions are installed is not easy either.
Comment 6 Olaf Felka 2012-05-25 12:44:37 UTC
I think that c1 is the right idea. As in OOo 3.x they should be installed at installation time in the shared layer of the installation. It would be nice to get the extensions back as selectable modules in the installation GUI.
Comment 7 zhao xia 2012-05-28 08:25:37 UTC
Move the version to AOO341, suggest fix thi one in AOO 341
Comment 8 Marcus 2012-05-28 08:59:12 UTC
Changed back to AOO340: Version: This field is to show the version where the problem has occurred first Target: This field is to set the release where it should be fixed.
Comment 9 Andre 2012-05-30 09:04:20 UTC
@Olaf: I chose the wrong words above. The points a), b) and c) are not alternatives. They each introduce a multiplier and have to be fixed separately. The multiplier of a) is 2, that of b) is something like 3 or 4 (a large thesaurus file is part of 4 or 5 extensions), and that of c) is the number of users.
Comment 10 Andre 2012-05-30 09:09:19 UTC
Created attachment 77808 [details] Extension manager creates the tmp repository on start up to trigger deletion of temporary data. A fix for a). Each repository already has code for cleaning up its temporary data. The tmp repository, which is responsible for one half of the 160MB, is just not triggered on start up. The fix does that.
Comment 11 Andre 2012-06-13 16:13:43 UTC
One technical part of installing extensions system wide is the following code snippet. It starts unopkg.exe with elevated access rights: HINSTANCE nResult (ShellExecute( NULL, "runas", "<office-path>\\program\\unopkg.exe", "gui", "<office-path>\\program", SW_SHOW)); For operating systems other than Windows we will need other solutions. But the main problem is how to convince the user/admin to type in her password. Just to recap, here is how the installation process could work with shared extensions: 1. Admin installs office (a user without admin rights can not elevate his access rights high enough to install anything). During the installation she is asked for her password to allow the installer to write into system directories (c:\Program Files or /usr/bin etc). It is operating system dependent of who does the asking, on Windows it is our installer, on Linux the package installer. 2. Office is started for the first time. Only at this stage we can install extensions (no installer on Mac, legal restrictions). In order to install them shared for all users we need elevated access rights a second time. Inconvenient but better then user install because of $TITLE. 3. Now the new part. Initiate the shared installation somewhere in the desktop module, where the user installation is started today. Show a dialog that tells the user that we are about to ask for his password, again, in order to install the extensions, and save his disk space. On his OK make a call like the one above which will result in the desktop code executed in another process with elevated rights. Install the extensions. 4. Everybody is happy.
Comment 12 Andre 2012-06-19 11:08:11 UTC
Assigning this issue to me, so that it does not get lost. On ooo-dev a discussion has started about dropping all english extensions but dict-en. All in favor, so far.
Comment 13 Andre 2012-06-19 12:06:25 UTC
I have created bug 120033 for dropping all english extensions except dict-en.oxt.
Comment 14 Andre 2012-06-25 14:24:44 UTC
I have created bug 120082 for cleaning up the temporary directory.
Comment 15 jsc 2012-06-27 07:06:53 UTC
set release blogger flag to 3.4.1
Comment 16 jsc 2012-06-27 09:05:42 UTC
remove release blocker flag for 3.4.1
Comment 17 Andrey Repin 2015-04-19 17:20:17 UTC
*** Issue 126236 has been marked as a duplicate of this issue. ***
Comment 18 Andrey Repin 2015-04-19 17:21:40 UTC
One alternative way of dealing with this is to unpack extensions into %LocalAppData% as duggested in #126236