Closed Bug 84896 Opened 23 years ago Closed 23 years ago

The program must close to allow a previous installation atempt to complete. Please wait.

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: dougkr, Assigned: slogan)

References

Details

(Whiteboard: [pdt+][smartupdate]9/28 verified on branch, [correctness])

Attachments

(6 files)

xpicleanup.dat file that wouldn't go away
525 bytes, application/octet-stream
Details
Unix utility changes to prevent "reboot deadlock"
2.33 KB, patch
Details | Diff | Splinter Review
Added removal of main try/sleep/try-again loop.
2.97 KB, patch
Details | Diff | Splinter Review
patch to shorten sleep cycle to 1 second
2.47 KB, patch
Details | Diff | Splinter Review
Corrent use of sleep() and unlink()
1019 bytes, patch
dveditz
: review+
slogan
: superreview+
Details | Diff | Splinter Review
it's in /usr/lib/mozilla
525 bytes, application/octet-stream
Details 
I had .9 installed & working.
I installed 0.9.1 - there is some confusion here I may have tried to
install twice.

now I have reinstalled - I have deleted - I have rebooted (blush), I have cried
but all I can get out of mozilla is the above comment!
dougkr@home.com - there must be some file hanging around which tells Mozilla 
that the installation is still in progress. Try reformatting your hard drive.

No, seriously - over to XPInstall to see if they can tell you what it is.

Gerv
Severity: blocker → major
Component: Browser-General → Installer: XPInstall Engine
.
Assignee: asa → ssu
Component: Installer: XPInstall Engine → Installer
QA Contact: doronr → gemal
QA Contact: gemal → gbush
over to syd.

That error generally means that the installer was not able to cleanup some files 
that are in use.

Under windows, there is a file called xpicleanup.dat that will get created in 
such an occasion.  Look for a file of the similar name under linux and try 
renaming it (make sure the browser is not running when you do this).  then try 
starting the browser up again.
Assignee: ssu → syd
That's exactly what's going on.  xpicleanup.dat must be in the main program
directory (the one that contains mozilla).  It's possible that this has been
left around because a file xpicleanup is trying to delete is now read-only for
some reason.
Since deleting the xpicleanup.dat could prossibly result in a non functional 
browser, I would suggest runing xpicleanup (under linux) before running the 
browser.  This should take care of files not yet replaced properly.  The browser 
should start right up afterwards.
*** Bug 84178 has been marked as a duplicate of this bug. ***
Syd/Don, perhaps we should think about doing a couple of things to the 
xpicleanup app:

 * Show some kind of UI when it's actually cleaning up files.  I know there are 
issues with knowing when it can actually cleanup files.  Perhaps show the UI 
after the first successfull file delete/rename/cleanup?
 * decrease the time interval that xpicleanup waits before attempting again to 
clean up files in memory.

Confirming this bug; it is real, it is nasty.

It just happened to me.  I run xpicleanup, it hangs.  I still can't run the browser.

Suggestions:

- Change the "The program must close to allow a previous installation atempt to
complete. Please wait." message to something that the user can cope with and
handle.  Give me a clue what I'm supposed to do next!  How long do I have to
wait?  How can I tell progress?  How do I know that things haven't just busted?
 Because, in my case, I'm damned sure things have just busted, but that's only
because I know how to run "ps" and see that there are no processes doing any
installation work for me.

- Rethink this whole thing.

You obviously have no idea how frustrating it is to the end user.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I got things to work eventually by killing the hung xpicleanup process I
started, and deleting xpicleanup.dat.  (Well, I renamed it, so you can have a
copy of it if that would be useful.)

Yes, the xpicleanup.dat file would be very useful to have.  xpicleanup probably
wasn't hung it just couldn't delete a file so it assumes that file is in use by
the browser.  It then waits and tries again.  We need to see what that file is
by looking inside xpicleanup.dat.

The file shouldn't be very big.  Can you post it to the bug?
nominating
Keywords: nsbeta1
Whiteboard: [smartupdate]
Ok, I opened the attached xpicleanup.dat and found: 
386a0c16a4808 (B)=/tmp/xpinstall.sh\0x00
in the delete list.

Terry: Is this file in your /tmp directory?  If so, what are the attributes on
the file?  Can it be deleted?
I checked for /tmp/xpinstall.sh and found the following:

-rwxr-xr-x    1 root     root          248 Nov  8  2000 xpinstall.sh
I have no such file in my /tmp.
Terry, would it be possible to put the xpicleanup.dat that you posted to the bug
in your "program" directory (same place as mozilla) and try running xpicleanup
by itself?  It should delete the xpicleanup.dat file almost immediately.
That's what I did originally!  /usr/local/mozilla is the directory that
contained both the mozilla executable and the xpicleanup.dat file.  When I ran
xpicleanup, it *hung*.  Only renaming it to xpicleanup.dat.sillybuggers let me
use mozilla at all.
I don't think xpicleanup actually hung.  I think it couldn't delete xpinstall.sh
in your /tmp directory at the time and so just kept on trying assuming it was in
use.  

Now that you've verified that there is no xpinstall.sh in your /tmp directory
I'd like to verify that xpicleanup just runs, deletes xpicleanup.dat and exits
correctly.
I'd definitely call it a program "hung" if it is busy infinite looping waiting
for some condition to happen that never does.

Anyway, you're right; xpicleanup now returns immediately, and the xpicleanup.dat
file disappears.
I encountered this after installing the java plugin on linux. Deleting the java
stuff from plugins/ fixed the problem.
I'm thinking that the java installer is installing a file as read only for some
reason.  If that's the case it can't be deleted by the cleanup app.  I'm looking
at that right now.
Looks like it's all read only but that shouldn't matter as long as you are the
same user running the "update" installation as the one who ran the original
installation.  If you're logged in as root when you install java the first time
and then another user when you install it again you won't be able to clean up
the initial installation.

Eric: Is it possible something like this occured in your case?
It's possible that is what happened to *me*.
*** Bug 87191 has been marked as a duplicate of this bug. ***
I've had this problem in Linux since 0.9.1 and with the nightly builds.  It's
always after I download the java plugin and exit mozilla.  Then I get the window
popup saying it's waiting for a previous installation attempt twice (start
mozilla twice) and then the third time I start mozilla it's fine forever until I
download the next nightly build.  =)  Occassionally it only gives the error
message one time, but 90% of the time it's twice until mozilla starts up.
*** Bug 88492 has been marked as a duplicate of this bug. ***
How long are you waiting after you exit mozilla after installing the java
plugin? Does waiting longer have any effect on the message at restart?  Try
waiting about 15 seconds.  If you're still getting the message at start up then
there's something that gets held open when the program exits.
So, Don, what do you suggest we do?
Target Milestone: --- → mozilla0.9.3
I suggest 2 things:
1. Shorten the sleep interval to 1 second instead of 15 seconds.
2. Put the try/sleep/try-again loops in the delete and replace routines rather
than in the main loop.  
3. Put a limit of 5 attempts per file then if it still can't delete the file it
should print the name of that file to a log file, delete it from the registry
and move on.  If if can't delete any file, throw a dialog that tells the user to
look at this log file.

If all this can't be done in the time allotted, we should at least do step 1, 2
and the "move on" part of 3.  We could skip the write-it-to-a-log-file part if
we had to.

This is my suggestion.
I don't know if this is known or not, but deleting the xpicleanup.dat 
file "fixes" this problem and I am able to get in to mozilla.
Yes, this is as designed.  The xpicleanup utility is supposed to read that file
and when all the entries have been processed it deletes it.  The browser then
uses the existance of the xpicleanup.dat file as a "flag" to determine if a
previous installation cleaned up correctly.  It's turning out that with some
complex plugin installs like java some files are marked for replacement but are
in use and stay in use even after the browser exits.
Oops.  That was "3" things.  No one expects the Spanish Inquisition!
I made the changes to the Unix version of xpicleanup.  These changes are:
1. Moved the loop to the delete and replace functions
2. Shortened the interval to 1 second and 5 retries
3. Always return DONE so that the entry in xpicleanup.dat gets deleted
4. Removed the loop from the main() function

I didn't do all the logging stuff but I don't believe that's as necessary as the
above changes.

Posting patch.
Blocks: 89424
Forgot the removal of the main try/sleep/try loop.  Posting new patch.
*** Bug 84639 has been marked as a duplicate of this bug. ***
*** Bug 91427 has been marked as a duplicate of this bug. ***
Shortening the interval to 1 second does the trick for me. The problem with the 
long interval is that when we launch the cleanup there's still a lot of mozilla 
shutdown left to go. The utility finds mozilla files still in use and 
immediately goes into its 15 second wait cycle, but by the time that's up the 
user has already tried to launch Mozilla again. Finding the files in-use the 
utility goes into another wait, while the user shuts down mozilla and 
relaunches, repeating the cycle ad nauseum unless the user happens to get lucky 
or the user gives up.

Moving the wait loop and giving up after a certain number of tries is just 
wrong and will surely lead to messed up installs. A better UI would be the 
ultimate solution (display the files being waited on? give the option to go 
ahead anyway?). But shortening the interval would be a good start.
PDT+.  Please ensure there are no undesirable side-effects...
Whiteboard: [smartupdate] → PDT+ [smartupdate]
r=selmer to the extent that the transformations from 15 seconds to 1 second look
correct on the face of it.
Checked in sleep cycle reduction on branch.
Adding vbranch keyword.
Keywords: vbranch
Whiteboard: PDT+ [smartupdate] → PDT+ [smartupdate] workaround fix on branch
sr=blake
OS: Linux → All
Hardware: PC → All
Checked in sleep cycle reduction on trunk.

I'm leaving the bug open because we need to do something different with the UI 
as well, and figure out how users can deal with "cleanups" that can never 
complete. (release note?)
verified on branch 
2001072504
Keywords: vbranch
Whiteboard: PDT+ [smartupdate] workaround fix on branch → PDT+ [smartupdate] workaround fix on branch/verified on branch
So - I have this bug too.. I have build id: 2001062815 (0.9.2) {Win2K)

I click on the puzzle piece to install Java plug in, it downloads
I get the "It worked" screen in netscape, Java setup program runs.

Next time I start Mozilla I expect Java to work.

Instead, I get this ".. previous installation..." message.

And Java is *STILL* not installed.

How do I install Java by hand? Are there but only a few files I have to twizzle
by hand with? or is it a bit more complicated, and I'm just going to have to wait.

I'd really like to have Java work in the browser.

-Duane.

*** Bug 92631 has been marked as a duplicate of this bug. ***
*** Bug 89051 has been marked as a duplicate of this bug. ***
Marking mostfreq at 11 dups.
Keywords: mostfreq
*** Bug 92880 has been marked as a duplicate of this bug. ***
Missed 0.9.3.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
*** Bug 93918 has been marked as a duplicate of this bug. ***
*** Bug 94005 has been marked as a duplicate of this bug. ***
*** Bug 94233 has been marked as a duplicate of this bug. ***
I'm also seeing the problem Dwane Ellis is getting where Java doesn't get
installed on Win2k (0.9.3).  I'm familiar with the xpicleanup problem from
Linux, so the "previous installation" message didn't faze me, but after running
xpicleanup the plugins folder is empty of Java plugins.

I guess this may be a separate W2k bug, but I'm not sure.
Err... sorry for the spam, but I want to be clear that I'm installing Java with
administrator privledges, so that isn't the issue.  Java is installed fine in
it's own folder, but mozilla/plugins is empty.
*** Bug 95215 has been marked as a duplicate of this bug. ***
*** Bug 95884 has been marked as a duplicate of this bug. ***
Grace, can I get an idea of what works, and where? Is there just a problem with
Java installs? What exactly are the steps to fix this.

I noticed that Dan's patch is on the trunk as well, although the status
whiteboard comments indicate only the branch has been verified.
Status: NEW → ASSIGNED
verify on mozilla 0.9.3 and trunk 2001090303

Dan, do you want to keep this open or should I mark verified?
*I* think it's fixed, but I'm a little concerned with all the complaints that
came in after I checked in the fix.  If you're not seeing it when installing the
JRE (on Linux especially) then go ahead and verify. Maybe we need a new bug for
a different underlying problem and starting fresh would probably help reduce
confusion.
Marking fixed based on Dan's comments.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
I'm still having the problem with the Sep 5, 2001 nightly build of mozilla, so
IMO this should be left open, or closed and reopened as a new bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Dan (stromberg): can you give me some steps to reproduce? I'd like to try this
myself. Grace: the majority of the bugs in here are Linux, but OS is set to ALL.
Is this true?
Status: REOPENED → ASSIGNED
mid air collision! Here are Dan's steps.  I see a few cases noted on Win, but 
most are on Linux- I will put PC/all

From Dan Stromberg's steps in email

The buildid is 2001090508.  I'm running mozilla, not netscape 6.x.  I
did the install as root, not as myself.  I didn't use the installer, I
just downloaded a .tar.gz, extracted, ran it as root, and attempted to
download the plugin, exited mozilla, reran it, and got the error.
I'll try to give you full detail of how I installed the plugin now:

1) run mozilla as root with HOME=/root and DISPLAY=seki.acs:5 (seki is my
   machine, :5 is for my mxconns X authorization)

2) I go to a java url (kgs.kisedo.com, "play go now" link)

3) I click "Ok" to download plugin

4) I select Java 2 linux plugin

5) In the "items to install" window, I click ok -without- highlighting an
option

6) Wait for the download to complete

7) In the "install results Java 2 plug-in for linux: successful"
window, I select "quit", to leave my root mozilla's.

8) I go back to my normal userid with DISPLAY=:0.0 and
HOME=/Dcs/staff/strombrg, and run mozilla again (same version), and
get the error in the subjectline.

I tried these steps with minor revisions. 
   did not have to change my display
 gunzipped and tarred the .gz file (did not use installer) as root
 went to java.sun.com
 downloaded java plugin (first time it was unsuccesful in downloading, second 
time it was ok)
 quit mozilla
 ran again as root/ got the 'please  wait ' message and waited about 15 seconds 
and launched successfully after that- checked out java page etc
 ran again as gbush after fiddling with permissions and launched etc.
Hardware: All → PC
There are still two error in InstallCleanupUnix.cpp:
1. sleep(1000) will sleep for 1000 seconds (about 16 minutes),
   not 1 second :-)
   If you want to sleep for 1 second, you'll need sleep(1)

2. unlink() syscall returns 0 on success, so instead of
        if(!unlink(aFileToDelete)) 
          return TRY_LATER;
 you need
        if(unlink(aFileToDelete) != 0)
          return TRY_LATER;

See attached patch 
Syd, are you happy with the patch from Denis?  Can we get it reviewed etc now?
Comment on attachment 49204 [details] [diff] [review]
Corrent use of sleep() and unlink()

r=dveditz -- we should push to get this PDT+
Attachment #49204 - Flags: review+
Keywords: nsbranch
Ooops, this bug had a leftover PDT+ from 6.1.  Removing that.  Moving from
nsbranch to nsbranch+, please correct me if I'm wrong.
Keywords: nsbranch → nsbranch+
Whiteboard: PDT+ [smartupdate] workaround fix on branch/verified on branch → [smartupdate] workaround fix on branch/verified on branch
0.9.4 is out the door.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
0.9.4 is out the door.
Pls get SR ASAP. We'd like to tak this one.
Still happens to me with 0.9.4.
Have a similar problem with java using build 20010917.  I killed the xpicleanup
process after installing the jre.xpi process manually restarted mozilla and
still got the comment box "Waiting for installation process to complete" or
whatever it says specifically.  I exited mozilla as root and ran as a user, this
time mozilla actually loaded without having to delete the plugin, however, when
I went to java.sun.com the browser completely hung.

I deleted the java2 directory and link from /usr/lib/mozilla/plugins and the
browser no longer hangs at java.sun.com.  

Incidentally I am able to get java working by downloading the java 2 sdk and
manually creating a libjavaplugin_oji.so link in /usr/lib/mozilla/plugins that
points to /usr/java/jdk1.3.1/jre/plugin/i386/ns600/libjavaplugin_oji.so
Whiteboard: [smartupdate] workaround fix on branch/verified on branch → [pdt][smartupdate] workaround fix on branch/verified on branch
*** Bug 100898 has been marked as a duplicate of this bug. ***
Adding correctness Status Whiteboard, correct/expected behavior does not occur.
Whiteboard: [pdt][smartupdate] workaround fix on branch/verified on branch → [pdt][smartupdate] workaround fix on branch/verified on branch, [correctness]
Mr. Syd - Tentative PDT+, pending your review. Pls Dan's review as sr =
Whiteboard: [pdt][smartupdate] workaround fix on branch/verified on branch, [correctness] → [pdt+][smartupdate] workaround fix on branch/verified on branch, [correctness]
r=syd
Attachment #49204 - Flags: superreview+
Syd - Pls check this in today (if possible).
Fixes checked in branch and trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
For the record, in case the world blows up as a result of this or anything, I
didn't sr= the patch that was checked in...
Checked in whitespace change with comment indicating true contribution and
review status of this fix.
Windows - updating doesn't result in the "please wait" dialog.

Linux - I don't know how to do an update on Linux, so I did an install which
deletes the existing installation.  How do I do a Linux update?

Mac - On the machine I have access to, it hangs, then crashes the machine while
trying to update.  After rebooting the machine, I see this dialog and need to
run xpicleanup.


To try installing java on Linux (I've been able to reproduce this previously
using these exact steps--haven't tried today):

1. Go to the plugins directory /usr/lib/mozilla/plugins using the rpm for RedHat.
2. delete the java2 directory rm -r java2
3. delete the libjavaplugin_oji.so link :  rm libjavaplugin_oji.so
4. Open the browser and go to http://java.sun.com

At this point it should be fairly straight-forward.  You should get the plugin
install dialog, just follow through and install the Linux Java2 plugin.  Once
you restart the browser you'll see if you get the xpiplugin error.  A good thing
to do if you don't get the xpiplugin bug, go back to java.sun.com and see if the
java plugin actually works.  Two weeks ago I was able to install plugin and get
mozilla to run, but it didn't actually run--see my previous workaround post.
OK, I can verify that it does not show the "...previous installation..." dialog.
 But when I run the browser again, the newly installed java plugin does not
work.  It hangs the browser.


From my debug build, some console output on the plugin init.

LoadPlugin()
/builds/eddyk/daily/mozilla/modules/plugin/samples/default/unix/libnullplugin.so
returned 8339318
GetMIMEDescription() returned "*:.*:All types"
IsPluginFile(/builds/eddyk/daily/mozilla/dist/bin/plugins/java2)
LoadPlugin: failed to initialize shared library
/builds/eddyk/daily/mozilla/dist/bin/plugins/java2
[/builds/eddyk/daily/mozilla/dist/bin/plugins/java2: cannot read file data: Is a
directory]
LoadPlugin() /builds/eddyk/daily/mozilla/dist/bin/plugins/java2 returned 0
IsPluginFile(/builds/eddyk/daily/mozilla/dist/bin/plugins/java2/plugin/i386/ns600/libjavaplugin_oji.so)
LoadPlugin: failed to initialize shared library
/builds/eddyk/daily/mozilla/dist/bin/plugins/java2/plugin/i386/ns600/libjavaplugin_oji.so
[/builds/eddyk/daily/mozilla/dist/bin/plugins/java2/plugin/i386/ns600/libjavaplugin_oji.so:
undefined symbol: _._13nsCOMPtr_base]
LoadPlugin()
/builds/eddyk/daily/mozilla/dist/bin/plugins/java2/plugin/i386/ns600/libjavaplugin_oji.so
returned 0



Hanging the browser is something entirely different. The check for an existing
xpicleanup.dat is the first thing, so you would get this warning long before it
tries to load java and hang.

Do you have a new kernel? AFAIK we're still using the 1.3.01 JRE which is known
to hang on RedHat 7.1 and similar unless you set some magic environment
variable. See the release notes.

The test for this bug is simple: 
 Install w/out Java
 visit a site that uses java (java.sun.com works)
 click the puzzle piece to get Java, install it
 exit and restart Mozilla.
If you get this message its still broken, if you don't it's fixed. Any other
problems installing Java (and there are a few known ones) are different bugs.

Mac is irrelevant to this bug's latest fixes, and even the original problem
wasn't reported on Mac.
commercial build  - branch 2001092804 (marking vtrunk to remind)
mozilla build 2001092813

changed status whiteboard to reflect current branch verification
Keywords: vtrunk
Whiteboard: [pdt+][smartupdate] workaround fix on branch/verified on branch, [correctness] → [pdt+][smartupdate]9/28 verified on branch, [correctness]
verified on trunk 2001100206
Status: RESOLVED → VERIFIED
Keywords: vtrunk
I received this error when trying to do a custom SmartUpdate from Nav,Mail,IM
only installation of 20010726 (N6.1 RTM) ... and did a full (every check box
clicked) installation of 20011002 update.html

I didn't get the error unless I attempt to open mail (which fails) than I quit
and restart.
Restart failed (with the error)
Second restart succeeded.


win2k
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Reclosing... this bug was not fixed until well after 6.1, so the 6.1 builds
still have the problem. When you update the install engine in the *existing*
version is used.

"SmartUpdate" in 6.1 is not supported and may or may not work (they killed the
site so bugs in this upgrade path slipped to low priority). If you find problems
please file new bugs. This message could come up in several cases and this bug
covers the case where the sleep cycle was too long, resulting in problems when
installing the JRE in mozilla.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
verified
Status: RESOLVED → VERIFIED
This problem ("The program must close to allow a previous installation...")
occurred on my Linux (RH 7.0) computer this week when running the Java plug-in
installation (http://home.netscape.com/plugins/jvm.html).  I read through all of
the comments in this bug and extracted a simple course of action that eventually
worked for  me.  I moved the xpicleanup.dat file from /usr/lib/mozilla-0.9.3/ to
/usr/local/mozilla/.  I then ran  xpicleanup that was located in
/usr/local/mozilla/ and the dat file disappeared and I was able to  launch
Mozilla, finally.  This seems like a flaw in the  Java Plug-in  installation
program:  placing the dat file in the wrong directory, or at least not making
the clean-up program aware of where the dat file can be found.  Anyway,  I
thought this tid-bit might be of interest.  Thanks for all of the verbose
discussions in the bug--it helped.

*** Bug 103647 has been marked as a duplicate of this bug. ***
*** Bug 105267 has been marked as a duplicate of this bug. ***
i've downloades today 10-24 the last mozilla from ximian
mozilla-0.9.5-ximian.1.i386.rpm and it's still have the same problem...how can i
fix it?..thank u
By "same problem" you mean installing the JRE and not being able to launch
after? Or are you installing something else first?

Run strings on xpicleanup.dat and see what path-like things you find in there.
That will let us know if it's safe to simply delete xpicleanup.dat, or give
clues to what install has left you in this state.
by "same problem" i mean installing the JRE and not being able to launch
after

I dont know what to do whe the xpicleanup.dat
 file...i'm gonna attach it...

    
    

    
  
Here's the output of running strings on Jorge's file:

$ strings attachment.cgi
ADdv
//lib/mozilla/plugins/java2/lib/i386/client/libjvm.so
ameserv
x32.gif
gin.mo
Users
Common
Version Registry
Private Arenas
Mozilla
XPInstall
Delete List
3911594733db7
/tmp/xpinstall.sh


    
    

    
  
i was looking at the file /usr/lib/mozilla/install.log and at the end there is a
 " [160/160]  Executing: /tmp/xpinstall.sh" and if u see the file 
/tmp/xpinstall.sh it says 
#!/bin/sh
#-------------------------------------------------------
# Hack to allow symlinking (required for Sun's JRE) in
# a zippy.
#
# usage: symlink.sh <srcfile> <newlink>
#
#-------------------------------------------------------
ln -s $1 $2

so...if xpinstall it's right...when java is installing...it tries to symlink
something...but xpinstall doesnt have arguments...

Am i right?


    
    

    
  
The script passes arguments, the log is incomplete for execute commands.

Delete the temp file and you should be fine. Would be nice to figure out why
xpicleanup was not able to do so (permission problem?).

    
    

    
  
what temp file? xpinstall?...i did it...actually i just moved it...and nothing
happens...i try to start mozilla and it doesnt...

    
    

    
  
*** Bug 102721 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: