Bug 107147 - oosetup deletes all files in users home directory
Summary: oosetup deletes all files in users home directory
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org   
(Show other bugs)
Version: rawhide
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Dan Williams
QA Contact:
Depends On:
Blocks: CambridgeBlocker
TreeView+ depends on / blocked
Reported: 2003-10-15 13:54 UTC by Steven Harms
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-02-27 16:42:52 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Here is the dialog responsible (46.25 KB, image/png)
2003-10-15 13:58 UTC, Steven Harms
no flags Details

Description Steven Harms 2003-10-15 13:54:59 UTC
Description of problem:
When running oosetup, and clicking the Remove OpenOffice 1.1.0 installation, if
during the next step you click "Delete all files" it will delete ALL files in
your home directory (which is not made clear, user assumes only all openoffice
related files)

Version-Release number of selected component (if applicable):
Open Office 1.1.0

How reproducible:
Run oosetup, click remove installation, click next, click delete all files,
click remove

Steps to Reproduce:
1. run oosetup
2. click remove installation -> next -> delete all files -> remove
Actual results:
All files in your home directory will be deleted

Expected results:
OpenOffice files would be deleted

Additional info:
Attaching a screenshot also

Comment 1 Steven Harms 2003-10-15 13:58:12 UTC
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!

Comment 2 Dan Williams 2003-10-15 15:18:45 UTC
This isn't very cool.  Bad OpenOffice.org, bad!  I'll look into it.

Comment 4 Dan Williams 2003-10-16 16:34:22 UTC
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?


Comment 5 Cosmotic 2003-10-17 07:55:46 UTC
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).

Comment 6 Dan Williams 2003-10-17 16:42:39 UTC
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.

Comment 7 Bojan Smojver 2003-10-23 07:43:12 UTC
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!

Comment 8 Bojan Smojver 2003-10-23 20:56:19 UTC
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.

Comment 9 Denice 2003-10-28 18:43:39 UTC
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:
   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.

Comment 10 Dan Williams 2003-10-28 18:49:49 UTC

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.

Comment 11 Bill Rugolsky, Jr. 2003-11-21 17:13:41 UTC
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.

Comment 12 Dan Williams 2004-02-27 16:42:52 UTC
Versions >= 1.1.0-20 don't create the link anymore.  Note however that
upgrades from previous installations will still ahve the problem.

Note You need to log in before you can comment on or make changes to this bug.