Issue 26539

hello,
thank you for using and supporting OpenOffice.Org!

can you please provide more information for reproducing your issue.
Which distribution are you using?

Please give us any information that might be relevant to your issue.

set prio P2 -> P3

Need more information about how to reproduce. A step by step walkthrough leading
to the problem would be very helpful.

Hi,

unfortunately I was not able to reproduce it manually. The problem occurs
occasionally. I'm using Slackware 9.1 with OOo 1.1.0 downloaded and installed
from .tar.gz binaries.

Thanks, MZ.

zanonmark,

i will close this issue for now,
please reopen it anytime, if you are able to reproduce it with the next major
release of OOo, 1.1.1, which should be released within the next very few weeks.

thank you,
max weber,
OOo volunteer

.

Hello. I have exactly the SAME DEFECT.
So I'll give you more details, config and A CLUE !

1. My config: SuSE Linux 9.2, KDE 3.3.2, PII 400MHz, 256Mb. Former SuSE 9.1,
same defect since quite a time.
2. My OOo: 1.1.4 but same defect under 1.1.3 and perhaps 1.1.2 (NOT BEFORE). I
don't use the quickstarter. My OOo is 100% standard; installed in /opt.
3a. What happens: from time to time part of options are lost, in my user account
& the same in other accounts. This is a RANDOM defect, not a periodic one. It's
quite difficult to determine under which conditions it arises. Every 30-50
restarts, say. 
3b. What happens: The Common.xcu file gets extra-small, 460 bytes, almost empty.
The other options remain unaffected.
4a. What to do !
I made a shell script, & I launch OOo by means of this. Here it is:
############## BEGIN OF SCRIPT
#!/bin/bash
pathOOo=`grep -m1 file $HOME/.sversionrc`
pathOOo=${pathOOo#OpenOffice*//}
pathopt=$pathOOo/user/registry/data/org/openoffice/Office
cp $pathopt/Common.xcu $pathopt/Common.xcu.backup
$pathOOo/soffice "$@"
taille=`filesize $pathopt/Common.xcu` 
if [ $taille -le 500 ] ; then 
# call KDE's kdialog utility
kdialog -warningcontinuecancel "OpenOffice.org just lost its options\n Redo from
last ?"
if [ $? -eq 0 ] ; then cp $pathopt/Common.xcu.backup $pathopt/Common.xcu ; fi
fi
############## END OF SCRIPT

4b. What to do next ?
I suggest that we could handle such misbehaviour in two ways.
- either add a mechanism allowing the user to save her/his preferences [options]
into a file, and later restore her/his choices again
- either modify the 'soffice' shell script so it could take care of the options
files (*.xcu) in a similar way to my own script.

Created attachment 21643 [details]
A shellscript launcher that takes care of the Common.xcu file, saves it, restores if necessary

reopening on rcabane's request received via email.

Now I can say a bit more about Common.xcu.

1. It seems that Common.xcu only increases in size. The mentioned defect happens
when Common.xcu becomes larger (typically > 40Kb). 

2. And the real defect is that Common.xcu gets completely lost ! So, at the next
fresh start, it's recreated from scratch and, of course, with very small size.

3. So I supposed that Common.xcu was a real mess. It is ! Mine had a lot of
sections like the following one:

   <node oor:name="h3" oor:op="replace">
    <prop oor:name="Filter" oor:type="xs:string">
     <value>StarOffice XML (Writer)</value>
    </prop>
    <prop oor:name="Password" oor:type="xs:string">
     <value/>
    </prop>
    <prop oor:name="Title" oor:type="xs:string">
     <value>mozmanual-version-1.0.sxw</value>
    </prop>
    <prop oor:name="URL" oor:type="xs:string">
     <value>file:///home/bob/documents/moz/mozmanual-version-1.0.sxw</value>
    </prop>
   </node>

and such, for a lot of documents I opened a long time ago.
I can't figure out why Common.xcu stores all that, but anyway it's a bug.

In enclose my (buggy) Common.xcu.

Created attachment 22138 [details]
Options (preferences) file from my OOo 1.1.4

This defect has nothing to do with the use of the "picklist" macro: it happens
for two distincts user accounts, my account uses picklist (level 11) and my
wife's account doesn't.

I lloked a bit inside the Common.xcu.
It has a lot of "history" nodes, which I find totally useless, and the required
picklist nodes.

Why so many history nodes ?

Robert

Confirming as a new issue.

I worked a bit onto this issue with the help of Cyrille Moureaux of Sun France.
We're looking for an explanation. 
It seems that 

1. the history (which is the list of previously opened files, organized as
nodes) fills without limit,

2. so the Common.xcu size contnuously increases,

3. and, at writing time, something weird happens.

As Common.xcu becomes greater, the probability of being corrupted increases
noticeably.

Hello

I have the same problem on Linux, and maybe I have a new element :

I lose the content of my common.xcu file just after I reach the 100th element of
the history list.

I mean, at one time, my common.xcu contains 100 elements in the history list : 
 <node oor:name="History">
  <node oor:name="List">
   <node oor:name="h0" oor:op="replace">
... to ...
   <node oor:name="h99" oor:op="replace">

The next time I'll start OO, I'll lose all the content of the common.xcu file.

Philippe

Bad news, guys.
I'm using OOo 2.0.1. And the same defect is there (still working under SuSE
Linux 9.3 + KDE 3.5).
Really, really annoying.

It seems to be happening for me, too.
I am using OO.o 2.0.1-5 with Debian testing.

John

It has happened again.  I restored my most recently backed up copy of
/home/john/.openoffice.org2/user/registry/data/org/openoffice/Office/Common.xcu
which restored my settings.

It had 1915 lines in it.  This seems to be related to issue 37201.  I took the
recent suggestion from from jipajapa Sun Apr 16 03:40:49 -0700 2006 on that
issue and deleted the history files.

Since the list in this file seems to grow without limit.  I have taken the
suggestion from http://oooauthors.org/en/FAQs/faqsetup/faqgeneralsetupgui/017
and inserted:
<prop oor:name="PickListSize" oor:type="xs:int">
<value>10</value>
</prop>

after:
<node oor:name="History">

in the hope that this may limit the number of entries.

John

It does not seem to - currently I have 20 items listed in it.

Also, does this issue need altering to indicate that it also affects Ooo 2?  Or
does a new issue need raising?

John

Hello. I'm using 2.0.3 since a good time (now switching to 2.0.4), and I didn't
notice this bug anymore. Could other testers confirm that ?

I am currently on OOo 2.0.4rc3.  I reset common.xcu to its default a few days
ago and it still seems to be filling up with recent documents - currently it has
24 entries.  I have not put the picklist value in since OOo now lists 10 items
by default.  I have yet to see whether common.xcu will reset.

I have raise this as a new issue 69802 . 

I've used 2.0.3 for a few months, and I could not find this bug. I'll see in 2.0.4.

marco

sorry, I meant: I've used ***2.0.2**...

*** Issue 69802 has been marked as a duplicate of this issue. ***

No idea what further information might be required, so '-needmoreinfo'

Currently I have some 115 items in the recent documents list and common.xcu is
at 57.9KB, so I am expecting it to disappear at any time.  Whether or not this
increase causes common.xcu to be deleted, this accumulation of recent documents
in the file is surely a bug in itself.
I am now on OOo 2.0.4.
By the way, I opened issue 69802 because this issue is still showing as a bug in
OOo 1.1.  How does it get to be recorded as affecting later versions?

An installation with this bug is definitively not reliable and more or less
unusable. I doubt that "Later" is an  appropriate time schedule.

@jwt:
What is your current LINUX version?
If your first name is "David": Can you please stop your e-mail system spamming
me with anti SPAM registration requests?

I am using a 2.6.18 kernel and Debian testing distribution.

John

It has just happened again.  Unfortunately, since it gets overwritten, I do not
know the state of common.xcu before it happened.

Hi, does this happen anymore using a newer build of OOo (e.g. OOo2.3)?

I'm using OOo2.3 on Ubuntu Linux 7.04 and don't get that problem...

Well, it has not reset for a while now, but currently I have some 120 items in
the recent documents list and common.xcu is at 54.6KB, so I am not holding my
breath.
I am currently on OO.o 2.2.1

Hello, since I'm using 2.3.1 I haven't seen that evil behaviour anymore.

... so I suggest we could CLOSE this issue.

Can a second user confirm this "works for me now with current version"?

I am now on 2.3.1 and the problem does not seem to have occurred recently.
Common.xcu is 54.7KB, so it is not growing.  There appears now to be a numbered
list of 10 picklist items and 100 history items, so presumably these lists are
now correctly limited.

closing issue.

closing. Feel free to reopen in case the problem still occurs in a current
version of OOo.