Issue 93163 - Office does not start after user data migration
Summary: Office does not start after user data migration
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOO300m3
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 3.0
Assignee: Martin Hollmichel
QA Contact: issues@framework
URL:
Keywords:
Depends on:
Blocks: 88888
  Show dependency tree
 
Reported: 2008-08-27 10:08 UTC by ab
Modified: 2009-07-20 15:58 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description ab 2008-08-27 10:08:10 UTC
If the user data migration finds basic in an old Office installation it
copies it to $(Office_OOO300_UserInst)/basic/__basic_80

When the Library Container sytem of the new Office are initialized the 
first time special migration code is executed. It merges the old Basic 
libraries contained in the __basic_80 folder into the new Basic instal-
lation. To do this a lot of move and copy operations are performed with
different Basic related folders.

For unclear reasons mostly one of these operation fails on MH's notebook.
This leads to a UCB exception that is not catched in the library contai-
ner code and finally prevents the Office from starting after the excep-
tion has been catched somewhere else.

Although this problem could not be reproduced anywhere else so far, it
makes sense to catch these exceptions in the library container code to
be on the save side for the Basic migration step.
Comment 1 ab 2008-08-27 11:48:38 UTC
STARTED
Comment 2 ab 2008-08-27 13:38:49 UTC
FIXED
Comment 3 ab 2008-08-27 14:12:50 UTC
ab->jsk: Concerning the automatic tests I think it's enough to run
the minimum set as only code is affected that refers to the Basic
user data migration. This code is not executed at all as long as
no __basic_80 folder exists in $(UserInst)/user/

This issue cannot be tested without some tricks as the fix should
only handle situations that normally don't occur anyway. But it's
not necessary to test the complete migration process as the fix 
only affects the Basic part that is triggered by the existance of 
the $(UserInst)/user/__basic_80 folder.

So to test the non-error scenario install a cws ab62 Office and
start it to get a User Installation. Disable the quickstarter.
Then copy a basic folder taken from an older installation to the
User installation using the name _basic_80 (I've copied you a 
sample containing a Standard and a Library1 lib to x:\jsk\ab62).
Now when restarting the Office and triggering Basic (e.g. by
creating a new writer doc or by directly starting swriter.exe
instead of soffice.exe) the migration should be performed. Libra-
ry1 should be imported and __basic_80 should be deleted.

To simulate the error scenario copy _basic_80 another time and
create an additional __basic_tmp folder. Now the migration will
fail, because __basic_tmp (that is used internally) exists.
This will force an Exception and allows you to test the clean up
mechanism that tries to rename _basic_80 to _basic_80_err to
at least keep the old macros even if the migration fails. So
afterwards __basic_tmp and _basic_80_err will still be in the
user inst folder, but after starting swriter.exe the Office
should start anyway.


ab->mh: Could you please also test ab62 on your "magic" ;-)
notebook? If you don't have an old installation any more that
forces the migration please also copy x:\jsk\ab62\__basic_80
to your user installation.
Comment 4 ab 2008-08-27 14:27:02 UTC
Additional information: On Linux the __basic_tmp trick seems to work
only if __basic_tmp is *not* empty, so please copy any file there.
Comment 5 joerg.skottke 2008-08-27 15:45:53 UTC
This appears to work on Windows and Linux. However, this should be tested in
real life as well, so i change the owner of this taks to mh.

@mh: Please test your scenario.
Comment 6 Martin Hollmichel 2008-08-28 08:36:57 UTC
verified.
Comment 7 thorsten.ziehm 2009-07-20 15:58:52 UTC
This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
http://download.openoffice.org/index.html
If you want to know more about the handling of fixed/verified issues =>
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues