Reassigned to SBA

Too late for beta2, re-targeted to 1.1 RC.

Thank you for using and supporting OOo.

Does this problem still exist in 1.1 Beta 2?

Unable to duplicate RH 9.0, 1.1 Beta 2.

We are unable to duplicate under Windows 2000, 1.1 Beta 2. Appears
corrected. -thanks

.

No, it's NOT fixed.  It just came up with a lot of users (Linux and
Windows) on the users' list.  It's a real show-stopper.  I'm not
willing to try it as I need those entries and everyone who's tried it
has had to reinstall RC4 to get them back.

1. Go to Tools | AutoCorrect/AutoFormat...
2. Choose the Replace tab.
3. Select the first entry in the list: Replace (c) with copyright symbol.
4. Click ok.
5. Close OpenOffice.org 1.1RC3.
6. Reopen OpenOffice.org 1.1RC3.
7. Repeat steps 1 and 2.
8. Now there is no list where there was a list under the Replace tab.

The entire replace table disappears when the first entry is deleted.
Before closing and opening OOo again, only the one entry was deleted.
When OOo was reopened, all of the list except for the one deleted line
should have shown.

My tests were on OOo 1.1RC3 running on RH9 linux.

Here is a link to the thread on the users list where we discovered this:
http://www.openoffice.org/servlets/ReadMsg?msgId=823475&listName=users

Tamblyne discovered this on the users list, and two of us reproduced it.

Changed target milestone from OOo 1.1RC to OOo 1.1.1.

dang...I left out a step in my previous procedure. Please add step
3a. Click Delete to remove the selected entry.

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

Ho Kay... 
however 19543 indicates that this puppy is STILL not fixed! 
I had this problem with 1.1RC4 and severial others had it as well. 
On most platforms. 
There should be a way of combining these issues comments. 
They are quite complete and this si a real show stopper for many folks. 
If you delete something out of the table and have to go back to a clean Bare 
metel reload to get it back... 
REal bad for most computer users... 
JIm TE 

SBA->OS: As discussed and reproduced: After the installation of OOo,
the autocorr files are in /../share/autocor/. After they get edited
for the first time, they get copied to /../user/autocor/. This works
if the first action is ADDING an entry. If the first action is a
deletion, the English autocor files do not get written.
So the workaround is to add an entry before deleting one. This means
that a "long list" of added entries can't get lost, only the initial
list can vanish.
Reassigned to Oliver.

The above comment doesn't seem to reflect my experience.  My
acor2057.dat file is already in ...\user\autocorr, and contains about
a dozen additions which I have put in.  Yet *sometimes* (not every
time!) when I delete an entry, the whole list disappears.  The
acor2057.dat file is still in ...\user\autocorr, but presumably is
corrupted in some way so can't be read (its "Date modified" shows the
time I made the deletion.)  I have a backup copy of the file which I
just copy back into that directory and that cures the problem until
the next time (quicker than reinstalling!).

I've tested it quite a few times, and what I can't find a pattern in
is when deleting an entry causes this problem and when it doesn't.  I
had thought it was only when deleting the first entry in the list -
not so.  Then I thought, only when deleting the most recent entry made
- not so.  It just seems to happen sometimes and not other times.

All this is with RC1 on WinXP by the way.

.

Just checking in with RC5 yes it still does it, I note the milestone is 1.1.1 
Cool Thanks. 
JIm TE 

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

I reproduced it by deleting the Copyright (C) symbol from the
English(US) list. I had no acor1033.dat file in the
../user/autocorrect directory for the test.
The result was a corrupted acor1033.dat zip-file that had an invalid
central directory. It was possible to repair it using zip -FF
acor1033.dat. I could not reproduce the problem with the German or the
French replace list.

The problem can be reproduced with any language, just a number of
entries must be removed.
The cause of the problem was that UCBStorage used internal buffering
in case storage is based on stream. During flashing the stream was not
truncated before writing, so in case the new version was smaller the
result would be a corrupted package.

Sending for testing.

Verified with cws = ok

Set to Verified

Here's a workaround courtesy of John Jordan:

Having spent hours struggling with this, I finally got some
information from people on the openoffice.org e-list. This is
definitely a bug. There is some question whether it is fixed and, even
if it is, evidently a patch file is not yet available. In the
meantime, if anyone gets bitten by this bug, the following will help
you cope until a patch is available --

1) There are usually several files in the /shared/autocorr folder, in
the format acor????.dat. There is one for each language you have
installed. For example, the acor1033.dat file is for English (USA).

2) When the user makes the first change to the AutoCorrect list and
clicks on OK in the dialog box window, the acor????.dat file for that
language is supposed to be copied to the /user/autocorr folder, the
new entry added to the file, and the file written with the date and
time stamp when the user made the change.

3) If the user deletes an entry from the list, the bug sometimes
causes the acor????.dat file in the /user/autocorr folder to be
corrupted, thus the list disappears from the dialog box. Or if the
first change the user makes is a deletion sometimes the acor????.dat
file is not copied to the /user/autocorr folder at all. Deleting an
entry does not always cause this behavior -- sometimes it works fine.

4) The user can add entries and edit existing entries without
problems. It's only deleting entries that is dangerous.

So to get around the problem until there is a fix available, do not
delete any entries. If an existing entry is causing you problems and
you want to get rid of it, just edit it so the replace field is the
same as the original field. E.g., if (C) > © is causing a problem,
just edit it so it changes (C) > (C).

Also, every time you make a change, go to your /user/autocorr folder,
select the newly changed file, and copy it to the same filename,
appending something like .backup. This will give you a backup copy of
your user AutoCorrect file, so if you inadvertently do something to
cause your list to disappear, you can just copy the backup file back
to it's original name. This will save doing a Repair or Reinstall to
get your AutoCorrect list back.

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

Reopen the issue to be checked in SRC680/readstorage

The fix is integrated to the SRC680/readstorage workspace also.

SBA: OK in Build srx645_m25s1-1_01.8733. Closed.