post-install replace

VERIFIED FIXED in mozilla0.9.4

Status

P1
normal
VERIFIED FIXED
18 years ago
3 years ago

People

(Reporter: dveditz, Assigned: slogan)

Tracking

Trunk
mozilla0.9.4
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [xpiprd][smartupdate])

Attachments

(12 attachments)

(Reporter)

Description

18 years ago
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
(Reporter)

Updated

18 years ago
Keywords: nsbeta1
Whiteboard: [xpiprd]
(Reporter)

Comment 1

18 years ago
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.
(Reporter)

Comment 2

18 years ago
Moz 0.8 tasks 
Target Milestone: --- → mozilla0.8

Comment 3

18 years ago
Top priority tasks
Priority: -- → P1

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: mozilla0.8 → mozilla0.9
(Assignee)

Updated

18 years ago
Keywords: nsbeta1 → nsbeta1+
(Reporter)

Updated

18 years ago
Depends on: 65679
(Reporter)

Updated

18 years ago
Depends on: 65680
(Reporter)

Comment 4

18 years ago
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]

Updated

18 years ago
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 5

18 years ago
adding jcall (Julie Call) to cc list
Julie, this is the bug we discussed at meeting

Comment 6

18 years ago
[ really cc'ing Julie ]

Comment 7

18 years ago
Posting diffs.  There will be one for the xpinstall directories and one for the
xpfe/bootstrap directory (the apprunner stuff)

Comment 8

18 years ago
Created attachment 34117 [details] [diff] [review]
xpinstall related changes

Comment 9

18 years ago
Created attachment 34118 [details] [diff] [review]
Patch to nsAppRunner.cpp and support files

Comment 10

18 years ago
Posting new diff based on comments from dveditz.

Comment 11

18 years ago
Created attachment 34608 [details] [diff] [review]
Apprunner-specific changes

Comment 12

18 years ago
Created attachment 34609 [details] [diff] [review]
Post Install Replace Utility and xpinstall changes

Comment 13

18 years ago
Forgot to attach the Mac InstallCleanupMac.cpp

Comment 14

18 years ago
Created attachment 34642 [details] [diff] [review]
InstallCleanupMac.cpp diff

Comment 15

18 years ago
Created attachment 34644 [details]
MANIFEST file to export InstallCleanupDefines.g

Comment 16

18 years ago
Created attachment 34646 [details]
MANIFEST file to put the OS message in the res directory

Comment 17

18 years ago
Created attachment 34648 [details] [diff] [review]
Mac build list diff

Comment 18

18 years ago
Created attachment 34651 [details]
InstallCleanupPrefix.h to be added to cleanup/macbuild

Comment 19

18 years ago
Created attachment 34652 [details]
InstallCleanupPrefix_debug.h to be added to cleanup/macbuild

Comment 20

18 years ago
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.

Comment 21

18 years ago
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

Comment 22

18 years ago
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

Updated

18 years ago
Blocks: 78246

Comment 23

18 years ago
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
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 24

18 years ago
Reopening as requested by dbragg.  Have something to add? ;-)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 25

18 years ago
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.

Comment 26

18 years ago
Created attachment 35670 [details] [diff] [review]
Browser.jst (install.js files in browser.xpi) changes to execute xpicleanup

Comment 27

18 years ago
r=sgehani

Comment 28

18 years ago
Created attachment 35683 [details] [diff] [review]
NS version of the browser.jst files.

Comment 29

18 years ago
r=sgehani for ns jst patch.

Comment 30

18 years ago
rs=mscott

Comment 31

18 years ago
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
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 32

18 years ago
Unable to fully verify due to Bug 80383.  It appears to work fine, if I 
artificially get around the problem.
Depends on: 80383

Comment 33

18 years ago
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

Comment 34

17 years ago
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 → ---
(Reporter)

Comment 35

17 years ago
Setting milestone, reassigning
Assignee: dbragg → syd
Status: REOPENED → NEW
Keywords: nsbranch
Target Milestone: mozilla0.9.1 → mozilla0.9.4
(Assignee)

Comment 36

17 years ago
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

Comment 37

17 years ago
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.
(Assignee)

Comment 38

17 years ago

*** This bug has been marked as a duplicate of 97334 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 39

17 years ago
Closing this fixed bug as a duplicate will mess with the stats
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Reporter)

Comment 40

17 years ago
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
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 41

17 years ago
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.

Comment 42

17 years ago
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.