Closed Bug 21734 Opened 20 years ago Closed 20 years ago

[Dogfood] NSMacInstaller does not download current .xpi files if .xpi files of same name are on the system

Categories

(SeaMonkey :: Installer, defect, P3, critical)

PowerPC
Mac System 8.5
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: agracebush, Assigned: samir_bugzilla)

Details

(Whiteboard: [PDT+])

Steps to reproduce:
1. Use NSMacInstaller to download and install a build (ie 1999121308)
2. Test etc
3. Clean system (delete mozregistry.dat/Documents or profile folder) and prepare
for new tests on 1999121408 build
4. Use NSMacInstaller to download and install build 1999121408

Actual results: Some files have 1213 dates (see also bug 21182), seamonkey shows
build date of 1999121308

Expected results: All files would have current 12/14 date and build date would
be 1999121408

Workaround: Restart system, browser.xpi file is still residing in Temp folder
and part of reboot is to clean that directory. If installer sees any .xpi file,
it will not download a new one - see bug 15695
Severity: major → critical
Summary: NSMacInstaller does not download current .xpi files if .xpi files of same name are on the system → [Dogfood] NSMacInstaller does not download current .xpi files if .xpi files of same name are on the system
Raising the severity to critial and nominating for dogfood, because
 - the mac temp file is invisible so you won't see it unless you go look at it
 - users don't always reboot their Mac. (I reboot my Mac everyday...of course I
crash everyday too :-))
 - this is really confusing and may cause additional bugs being logged that have
been already been fixed

my 2 cents
/Peter
Assignee: ssu → sgehani
changing assigned to Samir
Samir, I thought that the .xpi files get cleaned up after the install is done?
Status: NEW → ASSIGNED
The extracted core files get cleaned up, not the .xpis cause at the shutdown
stage we don't have any notion of whether they were already there or not (that's
still an open area until we implement MD5 checksums in the config.ini). At any
rate, we explicitly ask SmartDownload to download the .xpis. Need to investigate
whether SmartDownload is making the decision not to download if they already
exist, or we are.
Whiteboard: [PDT+]
Putting on PDT+ radar.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Fix checked in.
Status: RESOLVED → VERIFIED
build 1999121609
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.