Bug 107147

Created attachment 95204 [details]
Here is the dialog responsible

Here is the dialog that causes problem.  When it says delete all files, user
would assume openoffice related files, not entire home directory!

This isn't very cool.  Bad OpenOffice.org, bad!  I'll look into it.

Can you give me some details on your setup?  Did you upgrade from 1.0.2, or do a
clean install of Fedora Core with OOo 1.1.0?

Can you attach your ~/.sversionrc file to this bug?

Thanks,
Dan

I've encountered the same problem. Here, not all files were deleted - thankfully
- but still some quite important ones: KDE settings, Mozilla profile, Evolution
profile! :(

I've got no clue why exactly these...

BTW, it was an upgrade from 1.0.2-4 (Red Hat 9 RPMs).

Out of curiosity, why are you running oosetup rather than using RPM to manage
the installation?  One solution would be to remove the oosetup script
completely, since removal of the package should be done with RPM, as should and
repairs.  Trashing the .openoffice folder is the easiest way to kill it for
local users.

This happened to me when I ran setup from .xopenoffice directory on RHL 9 from
the Ximian distributed OOo 1.1 (i.e. xd-unstable channel), which makes me belive
this is really an OOo problem (see this issue:
http://www.openoffice.org/issues/show_bug.cgi?id=9623), not an RPM specific
problem (unless RH and Ximian created the same bug on purpose :-). I also think
I suffered from this once before, in the 1.0 days.

Luckily didn't have anything important in the home directory... Phew!

The culprit here could be ~/.openoffice/user/work directory, which is a symbolic
link back into ~. So if OOo decided to remove everything recursively and didn't
take into account that this is a link and not an actual directory, that might be
causing this unwanted cleanup.

Wow.  It really does delete files.  I successfully installed the beta3 rpms on a
couple of RH 9 systems here, with a couple of problems noted below.  Then I
experimented with another user account to understand some of the problems I had
encountered.  Anyway, with a properly functioning openoffice 1.1.0 setup, if you
then run oosetup and  pick delete all files, it will delete a bunch of files
outside of the .openoffice tree (but not all).  I had 1404 files before running
oosetup, and 331 files after.  Trees like .mozilla, .gnome*, nsmail, a source
tree and .kde were gone.  I rsynced back my files from a snapshot, repeated the
exercise running directly /home/admin/.openoffice/setup (which is, of course,
just a link to /usr/lib/openoffice/program/setup) and it happily deletes all the
files all over again.  So there is no problem with the oosetup script.

Some notes for people who wanted to experiment with OO 1.1 with RH 9:
 - after installing these RPMs, if you have a preexisting ~/.sversionrc file
   and you run ooffice (or oocalc, etc.) the installer would pop up and propose
   a new installation with the the complete dialogs for user information, and
   a choice between network and local installations.  The proposed install
   directory was:
     ~/OpenOffice.org1.1.0
   It would seem to succeed, but then exit without updating ~/.sversionrc
   and then propose to do it all over again the next time you tried to run 
   an OO application.

 - one should simply rename the ~/.sversionrc file before running any oo binary
   for the first time after installing these RPMs.  There was no need to delete
   ~/.openoffice/ if you want to get around the current problem.

Denice:

Can you try the setup/upgrade stuff with 1.1.0-3 or 1.1.0-4 (when it comes out).
 They solve most upgrade issues.

I removed the /usr/bin/oosetup because of this, users should not be removing OOo
using the OOo setup program until I get a chance to deal with this, which could
be a bit.  Removing the package should be done with RPM, not oosetup.  The
leftover bits would be each user's ~/.openoffice directory which can safely be
rm -rf'd.

It appears that there is still a problem with openoffice.org-1.1.0-6.
 Yesterday afternoon, my boss started a remote ooffice from our FC1
test machine, without removing his old OOo-1.0.1 .openoffice directory
and .sversionrc file. He stepped through the OOo upgrade dialog, which
seemed to take a very long time to complete.

We later discovered that *every* empty subdirectory of his home
directory tree, and all but four symlinks to (non-empty) directories
were removed.  We have as yet been unable to characterize why the four
symlinks were excepted; it doesn't appear to be related to
permissions, but they were all absolute paths under /usr.

Home directories on our network are mounted via NFS from a NetApp filer.

Versions >= 1.1.0-20 don't create the link anymore.  Note however that
upgrades from previous installations will still ahve the problem.