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

VERIFIED FIXED

Status

SeaMonkey
Installer
P3
critical
VERIFIED FIXED
18 years ago
13 years ago

People

(Reporter: Grace Bush, Assigned: Samir Gehani)

Tracking

Trunk
PowerPC
Mac System 8.5

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+])

(Reporter)

Description

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

Updated

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

Comment 1

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

Updated

18 years ago
Assignee: ssu → sgehani
(Reporter)

Comment 2

18 years ago
changing assigned to Samir

Comment 3

18 years ago
Samir, I thought that the .xpi files get cleaned up after the install is done?
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 4

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

Updated

18 years ago
Whiteboard: [PDT+]

Comment 5

18 years ago
Putting on PDT+ radar.
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 6

18 years ago
Fix checked in.
(Reporter)

Updated

18 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 7

18 years ago
build 1999121609
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.