To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=110198
User sb changed the following:
What |Old value |New value
================================================================================
Status|NEW |STARTED
--------------------------------------------------------------------------------
Target milestone|--- |OOo 3.3
--------------------------------------------------------------------------------
------- Additional comments from [email protected] Thu Mar 18 08:46:32 +0000
2010 -------
Issue 101955, integrated in DEV300_m74, completely changed the configmgr
implementation and its data file layout. There is code in place that shall
detect old user-layer configuration data ($UserInstallation/user/registry/data/)
and translate it on the fly into the new format
($UserInstallation/user/registrymodifications.xcu).
Issue 107083, integrated in DEV300_m72, removed the configuration property
/org.openoffice.Office.Common/AutoCorrect/ChangeFraction. Old user-layer
configuration data may contain a setting of this property. The old, pre-m74
configmgr implementation obviously ignored, but otherwise left alone, such
unknown elements in the user-layer configuration data (so the setting would have
survived moving user layers from pre-m72 to m73, and m73 OOo would have worked
fine).
The new configmgr implementation (since m74) fails to ignore such unknown
elements when translating old user-layer configuration data (it does ignore them
when reading its own format registrymodifications.xcu, it only fails during
on-the-fly translation). It then ignores the not-yet-translated remainder of
the old user-configuration data, which can arbitrarily lead to the symptoms
listed in this issue's original description.
The reason for the failure is explained in the comment at
configmgr/source/xcuparser.cxx l. 392--399: "TODO: Within
Components::parseModificationLayer (but only there) it can rightly happen that
data is read that does not match a schema (that no schema exists, or that the
schema specifies a different type), namely if the schema was brought along by an
extension that has been removed or replaced; instead of taking care of that at
all the relevant places, as a hack, only 'top-level' <item>s (that only appear
in modification layer data) with unknown path are filtered out here."
So here is a second reason that configuration data contains unknown elements
(apart from the extension scenario mentioned in the quoted comment): Schema
files are changed incompatibly between revisions, something the new configmgr
implementation did not anticipate. And those incompatible changes can not only
affect existing user-layer configuration data, but also existing extension-layer
configuration data.
While it is IMO debatable whether incompatible changes to schema files are
allowed, the easiest fix would be to ignore unknown elements when reading any
kind of xcu data, not just user-layer registrymodifications.xcu.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
