Closed Bug 65678 Opened 20 years ago Closed 19 years ago

post-install replace

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.4

People

(Reporter: dveditz, Assigned: slogan)

References

Details

(Whiteboard: [xpiprd][smartupdate])

Attachments

(12 files)

Need to switch install logic to do in-use file replacement *after* the product
has shut down rather than waiting for the next Mozilla re-start to do it. This
will solve several problems:
- 8.3 filename cruft on Win9x
- re-starting user may not have appropriate permissions
- could never re-register the XPInstall component itself
- the XPInstall library had to be loaded at startup every time to check
Keywords: nsbeta1
Whiteboard: [xpiprd]
Note we also have to continue to support the special WININIT replace mechanism
on Win9x for "system files", and we'll have to add a flag to
addFile/addDirectory to indicate which files should be treated this way.
Moz 0.8 tasks 
Target Milestone: --- → mozilla0.8
Top priority tasks
Priority: -- → P1
Status: NEW → ASSIGNED
Target Milestone: mozilla0.8 → mozilla0.9
Keywords: nsbeta1nsbeta1+
Depends on: 65679
Depends on: 65680
Rafael,Ed: this is the bug that will eliminate the need for reboot on Win9x; a
restart of the browser will still be required.
Whiteboard: [xpiprd] → [xpiprd][smartupdate]
Target Milestone: mozilla0.9 → mozilla0.9.1
adding jcall (Julie Call) to cc list
Julie, this is the bug we discussed at meeting
[ really cc'ing Julie ]
Posting diffs.  There will be one for the xpinstall directories and one for the
xpfe/bootstrap directory (the apprunner stuff)
Posting new diff based on comments from dveditz.
Forgot to attach the Mac InstallCleanupMac.cpp
Sorry for all the Mac postings but I'm not really great with Mac CVS.  The last 
two postings, InstallCleanupPrefix.h and InstallCleanupPrefix_debug.h were things 
we had to add to prevent the Mac compiler from optimizing out a bunch of code.   
They need to be added to xpinstall/cleanup/macbuild.
minor nit you don't have to change if you don't want to:

In nsAppRunner.cpp:
NS_WITH_SERVICE(nsIProperties, directoryService,
NS_DIRECTORY_SERVICE_CONTRACTID, &rv);
could be written as
nsCOMPtr<nsIProperteries> directoryService
(do_GetService(NS_DIRECTORY_SERVICE_CONTRACTID, &rv));

2) Does char* lastResortMessage = "..." need to be a localizeable string?
3) I wonder what the OS/2 implications of this showOSAlert dialog are? We should
fire an email off to mkaply letting him know about this file. (not a preq for
checking in tonight.
4)the last 2 InstallCleanuprefix diffs didn't look like there were changes
except to the copyright notice. Did those patches take correctly?
5) I didn't bother looking through the mac project / build list changes so I
hope you got those right =).

sr=-mscott

Thanks very much Scott.
* The lastResortMessage is only used in case the localizable message which is
read from cmessage.txt (I checked that in before the localization freeze and
didn't include it in the posting) couldn't be read for some reason.

* I'll make sure to contact mkaply on this.  I've been in contact with him and
javier on most of this project.  In fact, Javier gave me the OS/2 code.

* The InstallCleanupPrefix.h files are new files to the Mac.  I haven't cvs
added them yet so you don't see any cvs diff info in them.

* I hope I got the Mac build script changes right too.  Actually Samir did
almost all of the Mac work.  I've tested the Mac build twice now (with cvs
updates in between) and it seems to build just fine.

Thanks again for taking the time to look at this Scott.  I really appreciate it.

-Don
Blocks: 78246
Fix checked in.
To test this:
1. Do a clean installation.
2. Run the product and do an update installation. (update.html)
3. BEFORE exiting, look in the program's bin directory.  You should see some
files with .old or .new extenstions on them.  These are files that were locked
by the OS during the update installation.
4. Exit the program.
5. Look in the program's bin directory again.  You should see those .new/.old
files are now gone.  There should also be no xpicleanup.dat (XPICleanup Data on
the Mac) file in the bin directory.  If there is, some file is probably still
locked.
6. Restart the program.  If there was no xpicleanup.dat file it should just
start normally.  If there was/is an xpicleanup.dat file you should get an alert
saying a previous install didn't complete and the program needs to shut down.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Reopening as requested by dbragg.  Have something to add? ;-)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Why yes I do.  This bug/feature is fixed as far as 6.1 is concerned but 6.0
users doing an update install will have a problem.  I need to modify the
browser.jst files.  These eventually become install.js within the browser.xpi
file.  The modification checks to see if the user is running 6.0.  If so, it
explicitly executes xpicleanup.  6.1 has code to call xpicleanup when it exits
but 6.0x doesn't.

Poof!  I've got it fixed for Windows, Mac and Unix.  Posting patch.
r=sgehani
r=sgehani for ns jst patch.
rs=mscott
Zee feex eez checked in to both mozilla and NS trees.
Thanks to sgehani and mscott for the incredibly quick turn around.
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Unable to fully verify due to Bug 80383.  It appears to work fine, if I 
artificially get around the problem.
Depends on: 80383
Build: 2001-06-07-11-0.9.1(MAC), 2001-06-07-13-0.9.1(WIN), 
2001-06-07-13-0.9.1(LINUX)

Cleanup is after exiting browser.  This was checked in before branch, so marking 
Verified.
Status: RESOLVED → VERIFIED
Build: 2001-08-28-09-trunk(WIN)

This is back as being a problem on Win 98/ME.  We are having problems with 8.3.
 The browser will not launch after an update.html.

Marking Reopened!
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Setting milestone, reassigning
Assignee: dbragg → syd
Status: REOPENED → NEW
Keywords: nsbranch
Target Milestone: mozilla0.9.1 → mozilla0.9.4
Jimmy, I need more data. What exactly is the problem with 8.3? Not sure what to
look for here. Some steps to duplicate would be appreciated.
Status: NEW → ASSIGNED
1. From Win 98/ME, launch browser
2. Open an update.html to update to new build
(ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/2001-09-04-00-trunk/update.html)
3. Click Launch XPInstall button to update
4. Click OK button from Items to Install dialog
5. When updating is completed, exit browser and restart machine
6. Launch updated browser

RESULT:
Browser will not launch.  Checking Netscape directory shows that there are files
whose name ends in ~1.  Many of these files can be found in /chrome and /components

EXPECTED RESULT:
Browser launches.  All files replaced are properly named.

*** This bug has been marked as a duplicate of 97334 ***
Status: ASSIGNED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → DUPLICATE
Closing this fixed bug as a duplicate will mess with the stats
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
This can't be a duplicate of 97334 because that bug is a subset of this bug,
most of which is fixed.  Bug 97334 has two possible fixes, one of which is to
fix this one on Win98, too, the other is to resurrect the old ren8dot3 hack.

I think we should do the ren8dot3 hack to get us through the near future, then
fix this one the right way in the mozilla1.0-ish timeframe.

Re-closing as fixed, but 97334 will represent both approaches, I guess.
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
How ironic that the very first problem listed in this bug as things to be solved
by "post-install replace" is the very one that didn't get implemented.
Ok, we will track 8.3 file rename from Bug 97334.  If we want a more elegant
solution, this needs to be addressed outside this bug.  Marking this one verified.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.