Apache OpenOffice (AOO) Bugzilla – Issue 119272
user directory file size grows to 160mb due to bundled extensions
Last modified: 2017-05-20 10:44:50 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
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.
*** Issue 119359 has been marked as a duplicate of this issue. ***
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!
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.
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.
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.
Move the version to AOO341, suggest fix thi one in AOO 341
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.
@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.
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.
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.
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.
I have created bug 120033 for dropping all english extensions except dict-en.oxt.
I have created bug 120082 for cleaning up the temporary directory.
set release blogger flag to 3.4.1
remove release blocker flag for 3.4.1
*** Issue 126236 has been marked as a duplicate of this issue. ***
One alternative way of dealing with this is to unpack extensions into %LocalAppData% as duggested in #126236
Reset the assignee to the default "issues@openoffice.apache.org".