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

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P3)

Description

[Grace Bush]

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

Comment 1

[pmock]

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

Comment 2

[Grace Bush]

changing assigned to Samir

Comment 3

[Sean Su]

Samir, I thought that the .xpi files get cleaned up after the install is done?

Comment 4

[Samir Gehani]

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.

Comment 5

[leger]

Putting on PDT+ radar.

Comment 6

[Samir Gehani]

Fix checked in.

Comment 7

[Grace Bush]

build 1999121609