Issue 59171 - Shared configuration lost during update
Summary: Shared configuration lost during update
Alias: None
Product: Installation
Classification: Application
Component: code (show other issues)
Version: OOo 2.0.1
Hardware: All All
: P4 Trivial with 12 votes (vote)
Target Milestone: ---
QA Contact: issues@installation
Keywords: regression
Depends on:
Reported: 2005-12-10 10:02 UTC by andreschnabel
Modified: 2013-08-07 15:26 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Batch File for saveing dic files (4.15 KB, text/plain)
2005-12-18 14:45 UTC, colebantam
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description andreschnabel 2005-12-10 10:02:22 UTC
This is a follow up of issue 58847 (see for some more information there).

When upgrading OOo, several config files are overwritten (or deleted and created
anew). So, if you have a larger deployment with central configuration some of
this configuration is lost.

For normal users, this is e.g. visible with the dictionaries, as they will not
be available, because dictionary.lst is overwritten.

I think, the specification of the new installers misses some user needs, but
after all it hurts users like a bug.
As we are doing even micro updates zthis way and users need to get other bugs
fixed, they have to update. Arguments like "it is luck that the templates are
still available." are simply not acceptable for end users
Comment 1 andreschnabel 2005-12-10 10:03:33 UTC
setting regression keyword, as we were able to transfer those configuration data
wihtin 1.1.x codeline
Comment 2 colebantam 2005-12-10 18:53:27 UTC
Danke Andre, warst schon wieder schneller ;-)

Soll ich das mit dem "All USers/Anwendungsdaten" Ordner hier nochmal schreiben, 
oder reicht der Verweis auf dem alten Thread?

MfG, Claus

Comment 3 colebantam 2005-12-18 14:43:30 UTC
I wrote a small batchfile which reads the installation folder from the registry,
 and prompts the user afterwards if he wants to backup or restore the dic files.

It is written for german speacking users, but maybe someone wants to translate 
it into english ;-)

It may be usefull, as long as the update don't keep the installed dic's, which 
I fear will be the case for 2.0.1 at least...

Try to create a attachment...

I tested it only on XP, but should work on W2K to. Donst know for 9x...
Comment 4 colebantam 2005-12-18 14:45:02 UTC
Created attachment 32518 [details]
Batch File for saveing dic files
Comment 5 Olaf Felka 2006-01-24 09:07:27 UTC
Installation of OOo2.x is totaly different to 1.x.x. We need a new mechanism to
migrate these settings. Maybe e.g. additional dictionaries shouldn't be added to
a list that will be overwritten by installation. I think that is something that
has to be discussed by the several applications but not by 'installation'. So I
think in case of dictionaries that has to be discussed between laurentgodard and
tl. And I think that should be done in
@ is: What do you think?
Comment 6 2006-01-24 11:22:45 UTC
I think it would be fine to have an automatic update mechanism of files changed
by the user. But I also think, that we will not be able to offer this. We need a
merge/update mechanism for all files that could be changed by the user. And we
need this for all platforms. The attached batch file is a solution only for
dictinary.lst and only for Windows. Obviously xml files need a completely
different merge mechanism. And who knows? Tomorrow a new file is introduced,
that can be changed after the installation. Then again a new merge mechnism for
all platforms has to be implemented. This results in the problem that new files
are introduced by someone, without taking care of the update problem. Many
months later,  when the first update is available, we recognize the problem and
have to implement update/merge processes for this file  for all platforms. And
sometimes it can also be possible, that no update or merge is possible, for
example for customized pictures. No, I think this process will not work.
The only solution seems to be a new layer, which can be used to overwrite the
global settings made by the installation. But it cannot be allowed to change the
global settings made by the installation. So we have a user layer, that contains
the user specific settings. Then we need a new customization layer for settings
for all users. And then we have the global settings, that are available after
the installation. And this settings must not be changed, because all settings
are lost after update.  This seems to be a feasible scenario.

Comment 7 colebantam 2006-01-26 11:32:21 UTC
To correct an possible misunderstanding. DicBack.cmd was not intended as a "
solution" to the problem, but as a quick'n dirty workaround. I wrote it for my 
friends and customers to simplify the update from 2.0 to 2.0.1, and decided 
afterwards that it might be useful for others to, and that for attached it to 
this thread.

Shared Layer:
This proposal of "is" is what I mentioned in the previous thread. I wrote that 
there should be a OO Folder in "All Users\Application Data" which contains the 
shared data. Of course "is" wrote it more detailed and from a more "inside" 
technical view ;-) I hope this new layer can be introduced without many other 
Nevertheless, if OOo gets a new "layer", a "converter" would be fine...

I fear that targeting this issue to Version 3 is far to late! I think a 2.1 
Version Target would be much better. Also, I think that a solution for the 2.0.
x Series should be introduced. Of course it makes no sense to implement a merge 
system for every file that could be changed by users (as "is" said), but an 
simple switch (Don't update my Dictionarys) in the installer would solve the 
problem at first.

Comment 8 2006-06-27 11:22:50 UTC
Setting new target
Comment 9 2006-10-11 11:24:59 UTC
Comment 10 2007-11-26 14:13:54 UTC
Target OOo 3.0
Comment 11 2008-05-27 16:11:20 UTC
Target 3.1
Comment 12 kai.sommerfeld 2008-06-30 13:07:12 UTC
as Ingo wished... => 3.1
Comment 13 2008-12-10 12:13:07 UTC
New target again.
Comment 14 kai.sommerfeld 2011-02-09 16:31:02 UTC
is: Isn't it so that nowadays (OOo 3.3) the abovementioned 3rd -- the shared --
layer is already available?

- settings deployed with bundled extensions define "system" settings
- settings deployed with shared extensions define settings, which overrule
systems settings for all users - without physically(!) overwriting the system
- settings deployed with user extensions overrule bundled and shared settings

 Thus the solution for the problems mentioned above is not to overwrite settings
files in the office installation directory tree, but to deploy the settings in
question as shared extensions.

 Especially the problem with the dictionaries no longer should exist, as
dictionaries are extensions today.
Comment 15 2011-02-09 17:06:40 UTC
kso: Yes, for extensions we nowadays have this layering. So for dictionaries
this problem should no longer occur.
Comment 16 kai.sommerfeld 2011-02-10 12:35:07 UTC
As the original report is about problems with dictionaries and this is solved
now, I consider this issue resolved.
Comment 17 kai.sommerfeld 2011-02-10 12:35:33 UTC