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

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[Doug Robinson]

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!

Comment 1

[Gervase Markham [:gerv]]

[e-mail] - 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

Comment 2

[timeless]

.

Comment 3

[Sean Su]

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.

Comment 4

[dbragg]

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.

Comment 5

[Sean Su]

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.

Comment 6

[Sean Su]

*** Bug 84178 has been marked as a duplicate of this bug. ***

Comment 7

[Sean Su]

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.

Comment 8

[Terry Weissman]

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.

Comment 9

[Terry Weissman]

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.)

Comment 10

[dbragg]

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?

Comment 11

[Grace Bush]

nominating

Comment 12

[Terry Weissman]

Attachment: xpicleanup.dat file that wouldn't go away

Comment 13

[dbragg]

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?

Comment 14

[Darrell Brogdon]

I checked for /tmp/xpinstall.sh and found the following:

-rwxr-xr-x    1 root     root          248 Nov  8  2000 xpinstall.sh

Comment 15

[Terry Weissman]

I have no such file in my /tmp.

Comment 16

[dbragg]

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.

Comment 17

[Terry Weissman]

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.

Comment 18

[dbragg]

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.

Comment 19

[Terry Weissman]

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.

Comment 20

[Eric Vaandering (no email)]

I encountered this after installing the java plugin on linux. Deleting the java
stuff from plugins/ fixed the problem.

Comment 21

[dbragg]

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.

Comment 22

[dbragg]

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?

Comment 23

[Terry Weissman]

It's possible that is what happened to *me*.

Comment 24

[Matthias Versen [:Matti]]

*** Bug 87191 has been marked as a duplicate of this bug. ***

Comment 25

[subsolar]

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.

Comment 26

[Sean Su]

*** Bug 88492 has been marked as a duplicate of this bug. ***

Comment 27

[dbragg]

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.

Comment 28

[Syd Logan]

So, Don, what do you suggest we do?

Comment 29

[dbragg]

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.

Comment 30

[linux]

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.

Comment 31

[dbragg]

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.

Comment 32

[dbragg]

Oops.  That was "3" things.  No one expects the Spanish Inquisition!

Comment 33

[dbragg]

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.

Comment 34

[dbragg]

Attachment: Unix utility changes to prevent "reboot deadlock"

Comment 35

[dbragg]

Forgot the removal of the main try/sleep/try loop.  Posting new patch.

Comment 36

[dbragg]

Attachment: Added removal of main try/sleep/try-again loop.

Comment 37

[Dave]

*** Bug 84639 has been marked as a duplicate of this bug. ***

Comment 38

[Sean Su]

*** Bug 91427 has been marked as a duplicate of this bug. ***

Comment 39

[Daniel Veditz [:dveditz]]

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.

Comment 40

[Daniel Veditz [:dveditz]]

Attachment: patch to shorten sleep cycle to 1 second

Comment 41

[selmer (gone)]

PDT+.  Please ensure there are no undesirable side-effects...

Comment 42

[selmer (gone)]

r=selmer to the extent that the transformations from 15 seconds to 1 second look
correct on the face of it.

Comment 43

[Daniel Veditz [:dveditz]]

Checked in sleep cycle reduction on branch.

Comment 44

[selmer (gone)]

Adding vbranch keyword.

Comment 45

[Blake Ross]

sr=blake

Comment 46

[Daniel Veditz [:dveditz]]

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?)

Comment 47

[Grace Bush]

verified on branch 
2001072504

Comment 48

[duane ellis]

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.

Comment 49

[Xiaobin Lu]

*** Bug 92631 has been marked as a duplicate of this bug. ***

Comment 50

[Matthias Versen [:Matti]]

*** Bug 89051 has been marked as a duplicate of this bug. ***

Comment 51

[Jacek Piskozub]

Marking mostfreq at 11 dups.

Comment 52

[Matthias Versen [:Matti]]

*** Bug 92880 has been marked as a duplicate of this bug. ***

Comment 53

[Blake Ross]

Missed 0.9.3.

Comment 54

[Matthias Versen [:Matti]]

*** Bug 93918 has been marked as a duplicate of this bug. ***

Comment 55

[Dave]

*** Bug 94005 has been marked as a duplicate of this bug. ***

Comment 56

[Dave]

*** Bug 94233 has been marked as a duplicate of this bug. ***

Comment 57

[jhf]

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.

Comment 58

[jhf]

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.

Comment 59

[Dave]

*** Bug 95215 has been marked as a duplicate of this bug. ***

Comment 60

[Matthias Versen [:Matti]]

*** Bug 95884 has been marked as a duplicate of this bug. ***

Comment 61

[Syd Logan]

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.

Comment 62

[Grace Bush]

verify on mozilla 0.9.3 and trunk 2001090303

Dan, do you want to keep this open or should I mark verified?

Comment 63

[Daniel Veditz [:dveditz]]

*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.

Comment 64

[Syd Logan]

Marking fixed based on Dan's comments.

Comment 65

[Dan Stromberg]

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.

Comment 66

[Syd Logan]

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?

Comment 67

[Grace Bush]

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. 

Comment 68

[Denis Antrushin]

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 

Comment 69

[Denis Antrushin]

Attachment: Corrent use of sleep() and unlink()

Comment 70

[selmer (gone)]

Syd, are you happy with the patch from Denis?  Can we get it reviewed etc now?

Comment 71

[Daniel Veditz [:dveditz]]

Comment on attachment 49204 [details] [diff] [review]
Corrent use of sleep() and unlink()

r=dveditz -- we should push to get this PDT+

Comment 72

[selmer (gone)]

Ooops, this bug had a leftover PDT+ from 6.1.  Removing that.  Moving from
nsbranch to nsbranch+, please correct me if I'm wrong.

Comment 73

[Asa Dotzler [:asa]]

0.9.4 is out the door.

Comment 74

[Asa Dotzler [:asa]]

0.9.4 is out the door.

Comment 75

[Jaime Rodriguez, Jr.]

Pls get SR ASAP. We'd like to tak this one.

Comment 76

[Dan Stromberg]

Still happens to me with 0.9.4.

Comment 77

[Igor]

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

Comment 78

[Daniel Veditz [:dveditz]]

*** Bug 100898 has been marked as a duplicate of this bug. ***

Comment 79

[Jaime Rodriguez, Jr.]

Adding correctness Status Whiteboard, correct/expected behavior does not occur.

Comment 80

[Jaime Rodriguez, Jr.]

Mr. Syd - Tentative PDT+, pending your review. Pls Dan's review as sr =

Comment 81

[Syd Logan]

r=syd

Comment 82

[Jaime Rodriguez, Jr.]

Syd - Pls check this in today (if possible).

Comment 83

[Syd Logan]

Fixes checked in branch and trunk

Comment 84

[Blake Ross]

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...

Comment 85

[Daniel Veditz [:dveditz]]

Checked in whitespace change with comment indicating true contribution and
review status of this fix.

Comment 86

[eddyk]

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.

Comment 87

[Igor]

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.

Comment 88

[eddyk]

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.

Comment 89

[eddyk]

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

Comment 90

[Daniel Veditz [:dveditz]]

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.

Comment 91

[Grace Bush]

commercial build  - branch 2001092804 (marking vtrunk to remind)
mozilla build 2001092813

changed status whiteboard to reflect current branch verification

Comment 92

[Grace Bush]

verified on trunk 2001100206

Comment 93

[Chip Clark]

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

Comment 94

[Daniel Veditz [:dveditz]]

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.

Comment 95

[Grace Bush]

verified

Comment 96

[Russell Dyer]

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.

Comment 97

[Matthias Versen [:Matti]]

*** Bug 103647 has been marked as a duplicate of this bug. ***

Comment 98

[Matthias Versen [:Matti]]

*** Bug 105267 has been marked as a duplicate of this bug. ***

Comment 99

[Jorge Salinas]

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

Comment 100

[Daniel Veditz [:dveditz]]

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.

Comment 101

[Jorge Salinas]

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...

Comment 102

[Jorge Salinas]

Attachment: it's in /usr/lib/mozilla

Comment 103

[Dave]

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

Comment 104

[Jorge Salinas]

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?

Comment 105

[Daniel Veditz [:dveditz]]

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?).

Comment 106

[Jorge Salinas]

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

Comment 107

[Xan Lopez]

*** Bug 102721 has been marked as a duplicate of this bug. ***